Messages in this thread | | | Subject | Re: [Discussion v2] Usecases for the per-task latency-nice attribute | From | Parth Shah <> | Date | Thu, 24 Oct 2019 13:49:34 +0530 |
| |
On 9/30/19 4:13 PM, Parth Shah wrote: > Hello everyone, > > This is the v2 of the discussion started for introducing per-task > latency-nice attribute for providing scheduler hints. > > v1: https://lkml.org/lkml/2019/9/18/555 > > In brief, we face two challenges with the introduction of such attr. > > 1. Name: > ============== > ( Should be relevant to all the possible usecases, not confuse end-user and > reflect the functionality it provides to the scheduler behaviour ) > > Curated list of proposed names: > > 1. latency-nice: > should have a better understanding based on pre-existing concepts > > - But poses two interpretation ambiguity > a) -20 (least nice to latency, i.e. sacrifice latency for throughput) > +19 (most nice to latency, i.e. sacrifice throughput for latency) > b) -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) > > 2. 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 > > 3. latency-nasty > > 4. latency-sensible
+ 5. temper -20 (short temper, angry tasks, i.e., requires least latency) +19 (calm tasks, i.e., sacrifice latency for throughput)
> > > > 2. Value(s): > ============== > ( Boolean/Ternary, Range of values, profile tagging ) > > - Recent discussion plots the range of [-20, 19] to be the most agreed upon. > > 1. Range: > - [-20, 19]: > Which has similarities with the niceness concept and gives a minimal > continuous range. This can be on hand for things like scaling the > vruntime normalization [3] > > 2. Profile tagging: > - Can be used just like a flag attribute > e.g., Background, foreground, latency-sensible, reduce-idle-search, etc. > > 3. Binary: > - 0 for: Latency sensitive/sensible/in-tolerant/hungry... > - 1 for Latency insensitive/insensible/tolerant/nice-to-others/... > > Ternary: > - 0: no effect > - -1: require least latency > - +1: no restrictions in terms of lower/higher latency > > [...]
I guess the latency-tolerant name seems to be more relevant and the range [-20,19] will suit all the discussed usecases. ( ( ( tomatoes target here ) ) )
If this seems alright then I am thinking of writing out some patches to introduce p->latency-tolerant with the use of "sched_setattr" syscall.
Thanks, Parth
| |