All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Bellasi <patrick.bellasi@matbug.net>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	vschneid@redhat.com, linux-kernel@vger.kernel.org,
	parth@linux.ibm.com, qyousef@layalina.io, chris.hyser@oracle.com,
	David.Laight@aculab.com, pjt@google.com, pavel@ucw.cz,
	tj@kernel.org, qperret@google.com, tim.c.chen@linux.intel.com,
	joshdon@google.com, timj@gnu.org, kprateek.nayak@amd.com,
	yu.c.chen@intel.com, youssefesmat@chromium.org,
	joel@joelfernandes.org
Subject: Re: [PATCH v8 6/9] sched/fair: Add sched group latency support
Date: Mon, 14 Nov 2022 17:20:50 +0100	[thread overview]
Message-ID: <Y3Jq4gBB5+Qg67u7@google.com> (raw)
In-Reply-To: <20221110175009.18458-7-vincent.guittot@linaro.org>

Hi Vincent,

On 10-Nov 18:50, Vincent Guittot wrote:

[...]

> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> index be4a77baf784..a4866cd4e58c 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1095,6 +1095,16 @@ All time durations are in microseconds.
>          values similar to the sched_setattr(2). This maximum utilization
>          value is used to clamp the task specific maximum utilization clamp.
>  
> +  cpu.latency.nice
> +	A read-write single value file which exists on non-root
> +	cgroups.  The default is "0".
> +
> +	The nice value is in the range [-20, 19].
> +
> +	This interface file allows reading and setting latency using the
> +	same values used by sched_setattr(2). The latency_nice of a group is
> + used to limit the impact of the latency_nice of a task outside the
> + group.

This control model is not clear to me.

It does not seem matching what we have for uclamp, where the cgroup values are
used to restrict how much a task can ask or give (in terms of latency here).

in the uclamp's requested-vs-effective values model:

A) a task can "request" (or give up) latency as much as it likes

B) the cgroup in which the task is in any moment limits wthe maximum
   latency a task can "request" (or give up)

C) the system wide knob set the "request" limit for the root cgroup an any task
   not in a cgroup.

This model seems to be what we should use here too.

IOW, for each task compute an "effective" latency_nice value which is defined
starting for a task "requested" latency value and by restricting this value
based on the (B) cgroup value and the (C) system wide value.

That's what we do in uclamp_eff_get():
   https://elixir.bootlin.com/linux/v6.0/source/kernel/sched/core.c#L1484

Why such a model cannot be used for latency_nice too?
Am I missing something?


Best,
patrick

-- 
#include <best/regards.h>

Patrick Bellasi

  reply	other threads:[~2022-11-14 16:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 17:50 [PATCH v8 0/9] Add latency priority for CFS class Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 1/9] sched/fair: fix unfairness at wakeup Vincent Guittot
2022-11-14  3:06   ` Joel Fernandes
2022-11-14 11:05     ` Vincent Guittot
2022-11-16  2:10       ` Joel Fernandes
2022-11-16  8:25       ` Aaron Lu
2022-11-17  9:18         ` Vincent Guittot
2022-11-14 16:19   ` Patrick Bellasi
2022-11-14 16:46     ` Vincent Guittot
2022-11-14 19:13   ` Dietmar Eggemann
2022-11-15  7:26     ` Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 2/9] sched: Introduce latency-nice as a per-task attribute Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 3/9] sched/core: Propagate parent task's latency requirements to the child task Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 4/9] sched: Allow sched_{get,set}attr to change latency_nice of the task Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 5/9] sched/fair: Take into account latency priority at wakeup Vincent Guittot
2022-11-14 16:20   ` Patrick Bellasi
2022-11-15 15:40     ` Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 6/9] sched/fair: Add sched group latency support Vincent Guittot
2022-11-14 16:20   ` Patrick Bellasi [this message]
2022-11-14 16:57     ` Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 7/9] sched/core: Support latency priority with sched core Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 8/9] sched/fair: Add latency list Vincent Guittot
2022-11-10 17:50 ` [PATCH v8 9/9] sched/fair: remove check_preempt_from_others Vincent Guittot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3Jq4gBB5+Qg67u7@google.com \
    --to=patrick.bellasi@matbug.net \
    --cc=David.Laight@aculab.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=chris.hyser@oracle.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel@joelfernandes.org \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=parth@linux.ibm.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=qperret@google.com \
    --cc=qyousef@layalina.io \
    --cc=rostedt@goodmis.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=timj@gnu.org \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=youssefesmat@chromium.org \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.