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;
Subject: Re: [PATCH v2 0/3] Introduce per-task latency_tolerance for scheduler
 hints
To:     Dhaval Giani <dhaval.giani@oracle.com>
Cc:     linux-kernel@vger.kernel.org, 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, qperret@qperret.net,
        David.Laight@ACULAB.COM, pjt@google.com, tj@kernel.org,
        dietmar.eggemann@arm.com, Chris Deon Hyser <chris.hyser@oracle.com>
References: <20191208060410.17814-1-parth@linux.ibm.com>
 <5a13d54a-7e16-8d6c-8362-bd5f056004db@oracle.com>
From:   Parth Shah <parth@linux.ibm.com>
Date:   Thu, 16 Jan 2020 17:34:45 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <5a13d54a-7e16-8d6c-8362-bd5f056004db@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-Id: <a3fd8b12-1860-0f60-f8b1-ae97894b2eb4@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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
>