lkml.org 
[lkml]   [2019]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Discussion v2] Usecases for the per-task latency-nice attribute
From
Date


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

\
 
 \ /
  Last update: 2019-10-24 10:20    [W:0.063 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site