Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Parth Shah <parth@linux.ibm.com>
To:     linux-kernel@vger.kernel.org
Cc:     peterz@infradead.org, mingo@redhat.com, vincent.guittot@linaro.org,
        patrick.bellasi@matbug.net, valentin.schneider@arm.com,
        qais.yousef@arm.com, pavel@ucw.cz, dhaval.giani@oracle.com,
        qperret@qperret.net, David.Laight@ACULAB.COM,
        morten.rasmussen@arm.com, pjt@google.com, tj@kernel.org,
        dietmar.eggemann@arm.com, viresh.kumar@linaro.org,
        rafael.j.wysocki@intel.com, daniel.lezcano@linaro.org
Subject: [RFC 0/3] Introduce per-task latency_tolerance for scheduler hints
Date:   Mon, 25 Nov 2019 15:16:15 +0530
Message-Id: <20191125094618.30298-1-parth@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

This patch series is based on the discussion started as the "Usecases for
the per-task latency-nice attribute"[1]

This patch series introduces a new per-task attribute latency_tolerance to
provide the scheduler hints about the latency requirements of the task.

Latency_tolerance is a ranged attribute of a task with the value ranging
from [-20, 19] both inclusive which makes it align with the task nice
value.

The value should provide scheduler hints about the relative latency
requirements of tasks, meaning the task with "latency_tolerance = -20"
should have lower latency than compared to those tasks with higher values.
Similarly a task with "latency_tolerance = 19" can have higher latency and
hence such tasks may bot care much about the latency numbers.

The default value is set to 0. The usecases defined in [1] can use this
range of [-20, 19] for latency_tolerance for the specific purpose. This
patch does not define any use cases for such attribute so that any change
in naming or range does not affect much to the other (future) patches using
this. The actual use of latency_tolerance during task wakeup and
load-balancing is yet to be coded for each of those usecases.

As per my view, this defined attribute can be used in following ways for a
some of the usecases:
1 Reduce search scan time for select_idle_cpu():
- Reduce search scans for finding idle CPU for a waking task with lower
  latency_tolerance values.

2 TurboSched:
- Classify the tasks with higher latency_tolerance values as a small
  background task given that its historic utilization is very low, for
  which the scheduler can search for more number of cores to do task
  packing.  A task with a latency_tolerance >= some threshold (e.g, >= +18)
  and util <= 12.5% can be background tasks.

3 Optimize AVX512 based workload:
- Bias scheduler to not put a task having latency_tolerance==-20 on a core
  occupying AVX512 based workload.

Series Organization:
======================
- Patch [1]: Add new attribute latency_tolerance to task_struct
- Patch [2]: Clone parent task's attribute on fork
- Patch [3]: Add support to sched_{set,get}attr syscall to modify
  	     latency_tolerance of the task

The patch series can be applied on tip/sched/core at
commit 57abff067a08 ("sched/fair: Rework find_idlest_group()")


References:
===========
[1]. Usecases for the per-task latency-nice attribute,
     https://lkml.org/lkml/2019/9/30/215
[2]. Task Latency-nice, "Subhra Mazumdar",
     https://lkml.org/lkml/2019/8/30/829


Parth Shah (3):
  Introduce latency-tolerance as an per-task attribute
  Propagate parent task's latency requirements to the child task
  Allow sched_{get,set}attr to change latency_tolerance of the task

 include/linux/sched.h                   |  3 +++
 include/linux/sched/latency_tolerance.h | 13 +++++++++++++
 include/uapi/linux/sched.h              |  4 +++-
 include/uapi/linux/sched/types.h        |  2 ++
 kernel/sched/core.c                     | 19 +++++++++++++++++++
 kernel/sched/sched.h                    |  1 +
 6 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/sched/latency_tolerance.h

-- 
2.17.2