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

[Qais Yousef <qais.yousef@arm.com>]

On 09/18/19 18:11, Parth Shah wrote:
> Hello everyone,
> 
> As per the discussion in LPC2019, new per-task property like latency-nice
> can be useful in certain scenarios. The scheduler can take proper decision
> by knowing latency requirement of a task from the end-user itself.
> 
> There has already been an effort from Subhra for introducing Task
> latency-nice [1] values and have seen several possibilities where this type of
> interface can be used.
> 
> From the best of my understanding of the discussion on the mail thread and
> in the LPC2019, it seems that there are two dilemmas;
> 
> 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 and we can spend some more
> time in the kernel to decide a better placement of a task (to save time,
> energy, etc.)
> 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.
> 
> 2. Value: What should be the range of possible values supported by this new
> attr?
> ==============
> The possible values of such task attribute still need community attention.
> Do we need a range of values or just binary/ternary values are sufficient?
> Also signed or unsigned and so the length of the variable (u64, s32, etc)?

IMO the main question is who is the intended user of this new knob/API?

If it's intended for system admins to optimize certain workloads on a system
then I like the latency-nice range.

If we want to support application writers to define the latency requirements of
their tasks then I think latency-nice would be very confusing to use.
Especially when one has to consider they lack a pre-knowledge about the system
they will run on; and what else they are sharing the resources with.

> 
> 
> 
> This mail is to initiate the discussion regarding the possible usecases of
> such per task attribute and to come up with a specific name and value for
> the same.
> 
> Hopefully, interested one should plot out their usecase for which this new
> attr can potentially help in solving or optimizing it.
> 
> 
> Well, to start with, here is my usecase.
> 
> -------------------
> **Usecases**
> -------------------
> 
> $> TurboSched
> ====================
> TurboSched [2] tries to minimize the number of active cores in a socket by
> packing an un-important and low-utilization (named jitter) task on an
> already active core and thus refrains from waking up of a new core if
> possible. This requires tagging of tasks from the userspace hinting which
> tasks are un-important and thus waking-up a new core to minimize the
> latency is un-necessary for such tasks.
> As per the discussion on the posted RFC, it will be appropriate to use the
> task latency property where a task with the highest latency-nice value can
> be packed.
> But for this specific use-cases, having just a binary value to know which
> task is latency-sensitive and which not is sufficient enough, but having a
> range is also a good way to go where above some threshold the task can be
> packed.


$> EAS
====================
The new knob can help EAS path to switch to spreading behavior when
latency-nice is set instead of packing tasks on the most energy efficient CPU.
ie: pick the most energy efficient idle CPU.

--
Qais Yousef