Re: Usecases for the per-task latency-nice attribute

[Valentin Schneider]

On 19/09/2019 17:41, Parth Shah wrote:
> So jotting down separately, in case if we think to have "latency-nice"
> terminology, then we might need to select one of the 2 interpretation:
> 
> 1).
>> -20 (least nice to latency, i.e. sacrifice latency for throughput)
>> +19 (most nice to latency, i.e. sacrifice throughput for latency)
>>
> 
> 2).
> -20 (least nice to other task in terms of sacrificing latency, i.e.
> latency-sensitive)
> +19 (most nice to other tasks in terms of sacrificing latency, i.e.
> latency-forgoing)
> 
> 

I'd vote for 1 (duh) but won't fight for it, if it comes to it I'd be
happy with a random draw :D

>> Aren't we missing the point about tweaking the sched domain scans (which
>> AFAIR was the original point for latency-nice)?
>>
>> Something like default value is current behaviour and
>> - Being less latency-sensitive means increasing the scans (e.g. trending
>>   towards only going through the slow wakeup-path at the extreme setting)
>> - Being more latency-sensitive means reducing the scans (e.g. trending
>>   towards a fraction of the domain scanned in the fast-path at the extreme
>>   setting).
>>
> 
> Correct. But I was pondering upon the values required for this case.
> Is having just a range from [-20,19] even for larger system sufficient enough?
> 

As I said in the original thread by Subhra, this range should be plenty
enough IMO. You get ~5% deltas in each direction after all.

>>>
>>
>> $> Load balance tuning
>> ======================
>>
>> Already mentioned these in [4]:
>>
>> - Increase (reduce) nr_balance_failed threshold when trying to active
>>   balance a latency-sensitive (non-latency-sensitive) task.
>>
>> - Increase (decrease) sched_migration_cost factor in task_hot() for
>>   latency-sensitive (non-latency-sensitive) tasks.
>>
> 
> Thanks for listing down your ideas.
> 
> These are pretty useful optimization in general. But one may wonder if we
> reduce the search scans for idle-core in wake-up path and by-chance selects
> the busy core, then one would expect load balancer to move the task to idle
> core.
> 
> If I got it correct, the in such cases, the sched_migration_cost should be
> carefully increased, right?
> 

IIUC you're describing a scenario where we fail to find an idle core due to
a wakee being latency-sensitive (thus shorter scan), and place it on a rq
that already has runnable tasks (despite idle rqs being available).

In this case yes, we could potentially have a balance attempt trying to pull
from that rq. We'd try to pull the non-running tasks first, and if a
latency-sensitive task happens to be one of them we should be careful with
what we do - a migration could lead to unwanted latency.

It might be a bit more clear when you're balancing between busy cores - 
overall I think you should try to migrate the non-latency-sensitive
tasks first. Playing with task_hot() could be one of the ways to do that, but
it's just a suggestion at this time.

> 
>>>> References:
>>>> ===========
>>>> [1]. https://lkml.org/lkml/2019/8/30/829
>>>> [2]. https://lkml.org/lkml/2019/7/25/296
>>>
>>>   [3]. Message-ID: <20190905114709.GM2349@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>>>        https://lore.kernel.org/lkml/20190905114709.GM2349@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
>>>
>>
>> [4]: https://lkml.kernel.org/r/3d3306e4-3a78-5322-df69-7665cf01cc43@xxxxxxx
>>
>>>
>>> Best,
>>> Patrick
>>>
> 
> Thanks,
> Parth
>