mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Waiman Long <llong@redhat.com>
To: "Michal Koutný" <mkoutny@suse.com>, "Waiman Long" <llong@redhat.com>
Cc: Chen Ridong <chenridong@huaweicloud.com>,
	tj@kernel.org, hannes@cmpxchg.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org, lujialin4@huawei.com,
	chenridong@huawei.com
Subject: Re: [PATCH next] cpuset: Treat tasks in attaching process as populated
Date: Tue, 11 Nov 2025 15:35:57 -0500	[thread overview]
Message-ID: <a4e61aa0-5c1f-490e-9cae-5e478ba809ee@redhat.com> (raw)
In-Reply-To: <sebxxc2px767l447xr7cmkvlsewvdiazp7ksee3u2hlqaka522@egghgtj4oowf>

On 11/11/25 2:25 PM, Michal Koutný wrote:
> On Tue, Nov 11, 2025 at 10:16:33AM -0500, Waiman Long <llong@redhat.com> wrote:
>> For internal helper like this one, we may not really need that as
>> almost all the code in cpuset.c are within either a cpuset_mutex or
>> callback_lock critical sections. So I am fine with or without it.
> OK, cpuset_mutex and callback_lock are close but cgroup_is_populated()
> that caught my eye would also need cgroup_mutex otherwise "the result
> can only be used as a hint" (quote from cgroup.h).
>
> Or is it safe to assume that cpuset_mutex inside cpuset_attach() is
> sufficient to always (incl. exits) ensure stability of
> cgroup_is_populated() result?
>
> Anyway, I'd find some clarifications in the commit message or the
> surrounding code about this helpful. (Judgment call, whether with a
> lockdep macro. My opinion is -- why not.)

For attach_in_progress, it is protected by the cpuset_mutex. So it may 
make sense to add a lockdep_assert_held() for that.

You are right that there are problems WRT the stability of 
cgroup_is_populated() value.

I think "cgrp->nr_populated_csets + cs->attach_in_progress" should be 
almost stable for the cgroup itself with cpuset_mutex, but there can be 
a small timing window after cpuset_attach(), but before the stat is 
updated where the sum is 0, but there are actually tasks in the cgroup.

For "cgrp->nr_populated_domain_children + 
cgrp->nr_populated_threaded_children", it also has the problem that the 
sum can be 0 but there are attach_in_progress set in one or more of the 
child cgroups. So even with this patch, we can't guarantee 100% that 
there can be no task in the partition even if it has empty 
effective_cpus. It is only a problem for nested local partitions though 
as remote partitions are not allowed to exhaust all the CPUs from root 
cgroup.

We should probably document that limitation to warn users if they try to 
create nested local partitions where the parent partition root of the 
child partitions has empty effective_cpus.

Cheers,
Longman




  reply	other threads:[~2025-11-11 20:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 13:26 Chen Ridong
2025-11-11 14:01 ` Michal Koutný
2025-11-11 15:16   ` Waiman Long
2025-11-11 19:25     ` Michal Koutný
2025-11-11 20:35       ` Waiman Long [this message]
2025-11-12  1:58         ` Chen Ridong
2025-11-12  2:21           ` Waiman Long
2025-11-12  4:07             ` Chen Ridong
2025-11-12  1:42     ` Chen Ridong

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=a4e61aa0-5c1f-490e-9cae-5e478ba809ee@redhat.com \
    --to=llong@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=chenridong@huawei.com \
    --cc=chenridong@huaweicloud.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lujialin4@huawei.com \
    --cc=mkoutny@suse.com \
    --cc=tj@kernel.org \
    /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

all inboxes | Powered by JetHome®