Re: [PATCH v2 0/7] Add latency_nice priority
From: Chris Hyser
Date: Thu May 19 2022 - 14:15:00 EST
On 5/19/22 10:16 AM, Vincent Guittot wrote:
On Fri, 13 May 2022 at 23:44, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> wrote:
On Thu, 2022-05-12 at 18:35 +0200, Vincent Guittot wrote:
This patchset restarts the work about adding a latency nice priority to
describe the latency tolerance of cfs tasks.
The patches [1-4] have been done by Parth:
https://lore.kernel.org/lkml/20200228090755.22829-1-parth@xxxxxxxxxxxxx/
I have just rebased and moved the set of latency priority outside the
priority update. I have removed the reviewed tag because the patches
are 2 years old.
Vincent,
Thanks for introducing the feature again, which is much needed. I am trying
to look at the problem again from usage point of view. And wonder if
there are ways to make the latency_nice knob easier to use.
The latency nice value here is relative. A latency sensitive task
may not tell if setting the latency_nice to -5, or to -10 is good enough.
It depends on what other tasks are setting their latency_nice value to.
What a task does know is what it it doing and its characteristics.
For instance for client tasks, we may have categories such as
Task Category latency_nice_range
------------- ------------------
urgent -19 to -16
media playback -15 to -11
interactive (e.g.pressing key) -10 to -6
normal -5 to 9
background 10 to 15
opportunistic soaker task (sched_idle class) 16 to 20
And we could allow a task to set attribute of which task category applies
to it and the OS can set a default latency nice value in its task category.
So a task can just declare itself what kind of task it is, and not worry about
actually setting a latency nice value which it may not know
what is appopriate.
If needed, a task could still adjust its latency nice value within the range to
differentiate itself in a task category. And we will prevent
a task from seeting inappropriate latency nice value out of the right range.
The description above make sense but I'm not sure this should be put
as part of the interface but more in the documentation to describe how
system can make use of nice_latency
Knowing a task characteristics will also be helpful with other
scheduling decisions, like placing a task on a more high performing
core in hetero systems.
Ok so you would like a more general interface than an latency
interface but a way to set some attributes to a task so we can make
smarter decision
The original definition of latency nice was as a task attribute describing the latency sensitivity of the task. The fact
that it was mapped to 'nice' values created too much granularity and made it look more like a tuning knob than a
statement about the characteristics of the task as intended.
I think the missing piece here is a way for a task to declare
what kind of task it is. I think that will make things easier.
A classification of tasks into categories would be useful, but perhaps one level up in a user space tool or a user's
head (ie docs). For any of the categories you describe, there may be a number of per-task attributes beyond latency
sensitivity needed to capture the task characteristics you mention and ideally would be set in specific ways. Say 'nice'
values, oom kill, etc. And others may make sense in the future, like say NUMA sensitivity, etc.
Basically, a category can map to a bunch of desired default values for various scheduler visible task attributes.
Now you could also take the idea in the other direction where you set a "category value" for a task and have the kernel
pick the other attribute defaults like 'nice' that would typically apply to tasks in the category, but I think letting
user space figure stuff out and then set low level kernel task attributes primitives is cleaner.
-chrish