On 9/18/19 9:12 PM, Valentin Schneider wrote:
> On 18/09/2019 15:18, Patrick Bellasi wrote:
>>> 1. Name: What should be the name for such attr for all the possible
>>> usecases?
>>> =============
>>> Latency nice is the proposed name as of now where the lower value indicates
>>> that the task doesn't care much for the latency
>>
>> If by "lower value" you mean -19 (in the proposed [-20,19] range), then
>> I think the meaning should be the opposite.
>>
>> A -19 latency-nice task is a task which is not willing to give up
>> latency. For those tasks for example we want to reduce the wake-up
>> latency at maximum.
>>
>> This will keep its semantic aligned to that of process niceness values
>> which range from -20 (most favourable to the process) to 19 (least
>> favourable to the process).
>>
>
> I don't want to start a bikeshedding session here, but I agree with Parth
> on the interpretation of the values.
>
> I've always read niceness values as
> -20 (least nice to the system / other processes)
> +19 (most nice to the system / other processes)
>
> So following this trend I'd see for latency-nice:
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)
> However...
>
>>> But there seems to be a bit of confusion on whether we want biasing as well
>>> (latency-biased) or something similar, in which case "latency-nice" may
>>> confuse the end-user.
>>
>> AFAIU PeterZ point was "just" that if we call it "-nice" it has to
>> behave as "nice values" to avoid confusions to users. But, if we come up
>> with a different naming maybe we will have more freedom.
>>
>
> ...just getting rid of the "-nice" would leave us free not to have to
> interpret the values as "nice to / not nice to" :)
>
>> Personally, I like both "latency-nice" or "latency-tolerant", where:
>>
>> - latency-nice:
>> should have a better understanding based on pre-existing concepts
>>
>> - latency-tolerant:
>> decouples a bit its meaning from the niceness thus giving maybe a bit
>> more freedom in its complete definition and perhaps avoid any
>> possible interpretation confusion like the one I commented above.
>>
>> Fun fact: there was also the latency-nasty proposal from PaulMK :)
>>
>
> [...]
>
>>
>> $> Wakeup path tunings
>> ==========================
>>
>> Some additional possible use-cases was already discussed in [3]:
>>
>> - dynamically tune the policy of a task among SCHED_{OTHER,BATCH,IDLE}
>> depending on crossing certain pre-configured threshold of latency
>> niceness.
>>
>> - dynamically bias the vruntime updates we do in place_entity()
>> depending on the actual latency niceness of a task.
>>
>> PeterZ thinks this is dangerous but that we can "(carefully) fumble a
>> bit there."
>>
>> - bias the decisions we take in check_preempt_tick() still depending
>> on a relative comparison of the current and wakeup task latency
>> niceness values.
>
> 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?
>>
>
> $> 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?
>>> References:
>>> ===========
>>> [1]. https://lkml.org/lkml/2019/8/30/829
>>> [2]. https://lkml.org/lkml/2019/7/25/296
>>
>> [3]. Message-ID: <20190905114709.gm2...@hirez.programming.kicks-ass.net>
>>
>> https://lore.kernel.org/lkml/20190905114709.gm2...@hirez.programming.kicks-ass.net/
>>
>
> [4]: https://lkml.kernel.org/r/3d3306e4-3a78-5322-df69-7665cf01c...@arm.com
>
>>
>> Best,
>> Patrick
>>
Thanks,
Parth
