Re: [PATCH v2 0/3] Introduce per-task latency_tolerance for scheduler hints

[Dhaval Giani <dhaval.giani@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]



On 12/7/19 10:04 PM, Parth Shah wrote:
> This is the 2nd revision of the patch set to introduce latency_tolerance as
> a per task attribute.
>
> The previous version can be found at:
> v1: https://lkml.org/lkml/2019/11/25/151
>
> Changes in this revision are:
> v1 -> v2:
> - Addressed comments from Qais Yousef
> - As per suggestion from Dietmar, moved content from newly created
>   include/linux/sched/latency_tolerance.h to kernel/sched/sched.h
> - Extend sched_setattr() to support latency_tolerance in tools headers UAPI
>
>
> This patch series introduces a new per-task attribute latency_tolerance to
> provide the scheduler hints about the latency requirements of the task [1].
>
> 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 not care much about latency.
>
> The default value is set to 0. The usecases discussed below can use this
> range of [-20, 19] for latency_tolerance for the specific purpose. This
> patch does not implement 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.

Have you been able to adapt any of these use cases to this new interface?

Does the interface translate well to them?

Do you have any code that you can share?

Dhaval

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1799 bytes --]