mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Phil Auld <pauld@redhat.com>
Cc: linux-kernel@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Valentin Schneider <vschneid@redhat.com>,
	Ben Segall <bsegall@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mel Gorman <mgorman@suse.de>,
	Frederic Weisbecker <frederic@kernel.org>
Subject: Re: [PATCH v3 1/2] sched, cgroup: Restore meaning to hierarchical_quota
Date: Mon, 17 Jul 2023 08:27:24 -1000	[thread overview]
Message-ID: <ZLWIDC2nlG8cb3VE@slm.duckdns.org> (raw)
In-Reply-To: <20230714125746.812891-1-pauld@redhat.com>

On Fri, Jul 14, 2023 at 08:57:46AM -0400, Phil Auld wrote:
> In cgroupv2 cfs_b->hierarchical_quota is set to -1 for all task
> groups due to the previous fix simply taking the min.  It should
> reflect a limit imposed at that level or by an ancestor. Even
> though cgroupv2 does not require child quota to be less than or
> equal to that of its ancestors the task group will still be
> constrained by such a quota so this should be shown here. Cgroupv1
> continues to set this correctly.
> 
> In both cases, add initialization when a new task group is created
> based on the current parent's value (or RUNTIME_INF in the case of
> root_task_group). Otherwise, the field is wrong until a quota is
> changed after creation and __cfs_schedulable() is called.
> 
> Fixes: c53593e5cb69 ("sched, cgroup: Don't reject lower cpu.max on ancestors")

Does this really fix anything observable? I wonder whether this is more
misleading than helpful. In cgroup2, the value simply wasn't being used,
right?

> Signed-off-by: Phil Auld <pauld@redhat.com>
> Reviewed-by: Ben Segall <bsegall@google.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
> Cc: Valentin Schneider <vschneid@redhat.com>
> Cc: Ben Segall <bsegall@google.com>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Tejun Heo <tj@kernel.org>

Acked-by: Tejun Heo <tj@kernel.org>

> +		 * always take the non-RUNTIME_INF min.  On cgroup1, only
> +		 * inherit when no limit is set. In both cases this is used
> +		 * by the scheduler to determine if a given CFS task has a
> +		 * bandwidth constraint at some higher level.

The discussion on this comment is stretching too long and this is fine too
but what's worth commenting for cgroup2 is that the limit value itself
doesn't mean anything and we're just latching onto the value used by cgroup1
to track whether there's any limit active or not.

Thanks.

-- 
tejun

  reply	other threads:[~2023-07-17 18:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-12 13:33 [PATCH v6 0/2] Fix nohz_full vs cfs bandwidth Phil Auld
2023-07-12 13:33 ` [PATCH v2 1/2] sched, cgroup: Restore meaning to hierarchical_quota Phil Auld
2023-07-12 22:09   ` Benjamin Segall
2023-07-13 13:23     ` Phil Auld
2023-07-13 20:12       ` Benjamin Segall
2023-07-13 23:27         ` Phil Auld
2023-07-14 12:57     ` [PATCH v3 " Phil Auld
2023-07-17 18:27       ` Tejun Heo [this message]
2023-07-18 12:57         ` Phil Auld
2023-07-18 13:25           ` Phil Auld
2023-08-09 19:34       ` [tip: sched/core] " tip-bot2 for Phil Auld
2023-07-12 13:33 ` [PATCH v6 2/2] Sched/fair: Block nohz tick_stop when cfs bandwidth in use Phil Auld
2023-07-12 22:11   ` Benjamin Segall
2023-07-13 13:25     ` Phil Auld
2023-07-31 22:49   ` Peter Zijlstra
2023-08-01 11:13     ` Phil Auld
2023-08-01 15:37       ` Peter Zijlstra
2023-08-02 14:20         ` Phil Auld
2023-08-09 19:34   ` [tip: sched/core] sched/fair: " tip-bot2 for Phil Auld
2023-07-31 15:17 ` [PATCH v6 0/2] Fix nohz_full vs cfs bandwidth Phil Auld
2023-07-31 16:38 ` Phil Auld
2023-07-31 17:23   ` Phil Auld

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=ZLWIDC2nlG8cb3VE@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=frederic@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome