linux-kernel - Re: [PATCH v2 0/7] Add latency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f1f50c52673aa1873b4a4d3b6b15250d4bf390f9.camel@linux.intel.com>
Date:   Fri, 13 May 2022 14:44:37 -0700
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>, mingo@...hat.com,
        peterz@...radead.org, juri.lelli@...hat.com,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
        linux-kernel@...r.kernel.org, parth@...ux.ibm.com
Cc:     qais.yousef@....com, chris.hyser@...cle.com,
        valentin.schneider@....com, patrick.bellasi@...bug.net,
        David.Laight@...lab.com, pjt@...gle.com, pavel@....cz,
        tj@...nel.org, qperret@...gle.com, joshdon@...gle.com,
        len.brown@...el.com
Subject: Re: [PATCH v2 0/7]  Add latency_nice priority

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@linux.ibm.com/
> 
> 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.

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.  

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.

Tim

> The patches [5-7] use latency nice priority to decide if a cfs task can
> preempt the current running task. Patch 5 gives some tests results with
> cyclictests and hackbench to highlight the benefit of latency nice
> priority for short interactive task or long intensive tasks.
> 
> 
> Change since v1:
> - fix typo
> - move some codes in the right patch to make bisect happy
> - simplify and fixed how the weight is computed
> - added support of sched core patch 7
> 
> Parth Shah (4):
>   sched: Introduce latency-nice as a per-task attribute
>   sched/core: Propagate parent task's latency requirements to the child
>     task
>   sched: Allow sched_{get,set}attr to change latency_nice of the task
>   sched/core: Add permission checks for setting the latency_nice value
> 
> Vincent Guittot (3):
>   sched/fair: Take into account latency nice at wakeup
>   sched/fair: Add sched group latency support
>   sched/core: support latency nice with sched core
> 
>  include/linux/sched.h            |   3 +
>  include/uapi/linux/sched.h       |   4 +-
>  include/uapi/linux/sched/types.h |  19 ++++++
>  init/init_task.c                 |   1 +
>  kernel/sched/core.c              |  90 ++++++++++++++++++++++++++
>  kernel/sched/debug.c             |   1 +
>  kernel/sched/fair.c              | 105 ++++++++++++++++++++++++++++++-
>  kernel/sched/sched.h             |  34 ++++++++++
>  tools/include/uapi/linux/sched.h |   4 +-
>  9 files changed, 257 insertions(+), 4 deletions(-)
>