Message-Id: <a3fd8b12-1860-0f60-f8b1-ae97894b2eb4@linux.ibm.com>
Date:   Thu, 16 Jan 2020 17:34:45 +0530
From:   Parth Shah <parth@...ux.ibm.com>
To:     Dhaval Giani <dhaval.giani@...cle.com>
Cc:     linux-kernel@...r.kernel.org, peterz@...radead.org,
        mingo@...hat.com, vincent.guittot@...aro.org,
        patrick.bellasi@...bug.net, valentin.schneider@....com,
        qais.yousef@....com, pavel@....cz, qperret@...rret.net,
        David.Laight@...LAB.COM, pjt@...gle.com, tj@...nel.org,
        dietmar.eggemann@....com, Chris Deon Hyser <chris.hyser@...cle.com>
Subject: Re: [PATCH v2 0/3] Introduce per-task latency_tolerance for scheduler
 hints

Hi Dhaval,

On 1/16/20 2:03 AM, Dhaval Giani wrote:
> 
> 
> 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?

Yes, I am able to adapt this patch set for TurboSched and proves useful for
classifying low latency requiring tasks and pack those on fewer number of
cores. I am able to pack the tasks having
latency_tolerance==MAX_LATENCY_TOLERANCE.

I will send the RFC v6 of the TurboSched soon on the lkml, which uses the
latency_{nice/tolerance}.


Thanks,
Parth

> 
> Dhaval
> 

Powered by blists - more mailing lists