Date:   Mon, 23 May 2022 14:52:19 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
Cc:     Chris Hyser <chris.hyser@...cle.com>, 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,
        qais.yousef@....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 Fri, 20 May 2022 at 20:46, Tim Chen <tim.c.chen@...ux.intel.com> wrote:
>
> On Thu, 2022-05-19 at 14:14 -0400, Chris Hyser wrote:
> > On 5/19/22 10:16 AM, Vincent Guittot wrote:
> > > On Fri, 13 May 2022 at 23:44, Tim Chen <tim.c.chen@...ux.intel.com> 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@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.
> > >
> > > 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.
>
> Yes.  I think having a default value for each category will make the setting of the attributes
> consistent and life of a task simpler.
>
> Without guidance, one media playback task can set its latency_nice to be -5,
> and another interactive task doing computation and displaying results to user
> set its latency_nice to be -6. We would have the interactive task running ahead of the media playback,
> which is undesired.  Just letting each task set its own latency_nice value will not achieve the
> desired effect.  We need guidance on what attribute value a certain task category
> should use (as in documentation that Vincent mentioned).
>
> Or let OS set the attribute to some sensible value if it knows the task category.

I'm in favor of documentation that provides guidance rather than the
OS setting attribute because the values are relative to each others so
we will always find some exceptions to a default configuration for let
say media vs user interaction. With a documentation, someone can
always not follow it if he thinks it doesn't apply to his system
because of whatever the reason. With the OS setting attributes, this
exception will have to abuse its category to get the right priority vs
others

>
> >
> > 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.
>
> It is cleaner for the OS to give the knob to the user and say, "set it".
> But users need guidance on what knob value they should use,
> or even better, they don't need to worry about setting the knob.
> I think it is easy for the user to set task category correctly, but
> harder to set the low level knobs.
>
> I can see that it is easy to set the latency_nice knob incorrectly.
> The absolute value of the knob doesn't matter. Only the relative values
> between tasks do. So we need all the tasks to agree on what latency-nice
> to use for a task category.
>
> Tim
>
>
> >
> > -chrish
>

Powered by blists - more mailing lists