From: Tejun Heo <tj@kernel.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "Waiman Long" <llong@redhat.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Clark Williams" <clrkwllms@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-rt-devel@lists.linux.dev,
"Chen Ridong" <chenridong@huawei.com>,
"Pingfan Liu" <piliu@redhat.com>,
"Juri Lelli" <juri.lelli@redhat.com>
Subject: Re: [cgroup/for-6.19 PATCH] cgroup/cpuset: Make callback_lock a raw_spinlock_t
Date: Thu, 13 Nov 2025 06:25:29 -1000 [thread overview]
Message-ID: <aRYGeduETy3RPnFK@slm.duckdns.org> (raw)
In-Reply-To: <20251113075356.Ix4N-p8X@linutronix.de>
Hello,
On Thu, Nov 13, 2025 at 08:53:56AM +0100, Sebastian Andrzej Siewior wrote:
> On 2025-11-12 13:21:12 [-0500], Waiman Long wrote:
> > On 11/12/25 3:51 AM, Sebastian Andrzej Siewior wrote:
> > > On 2025-11-11 22:57:59 [-0500], Waiman Long wrote:
> > > > The callback_lock is a spinlock_t which is acquired either to read
> > > > a stable set of cpu or node masks or to modify those masks when
> > > > cpuset_mutex is also acquired. Sometime it may need to go up the
> > > > cgroup hierarchy while holding the lock to find the right set of masks
> > > > to use. Assuming that the depth of the cgroup hierarch is finite and
> > > > typically small, the lock hold time should be limited.
> > > We can't assume that, can we?
> > We can theoretically create a cgroup hierarchy with many levels, but no sane
> > users will actually do that. If this is a concern to you, I can certainly
> > drop this patch.
>
> Someone will think this is sane and will wonder. We usually don't impose
> limits but make sure things are preemptible so it does not matter.
It's always better to be scalable but note that there are cases where the
overhead of nesting can't be hidden completely without significant
sacrifices in other areas and we don't want to overindex on depth
scalability at the cost of practical capabilities. This is also why cgroup
depth is a limited resource controlled by cgroup.max.depth knob.
If something works well with, say, 16 levels of nesting, it's already mostly
acceptable.
Thanks.
--
tejun
next prev parent reply other threads:[~2025-11-13 16:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 3:57 [cgroup/for-6.19 PATCH] cgroup/cpuset: Make callback_lock a raw_spinlock_t Waiman Long
2025-11-12 8:51 ` Sebastian Andrzej Siewior
2025-11-12 18:21 ` Waiman Long
2025-11-13 7:53 ` Sebastian Andrzej Siewior
2025-11-13 16:25 ` Tejun Heo [this message]
2025-11-13 16:35 ` Waiman Long
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=aRYGeduETy3RPnFK@slm.duckdns.org \
--to=tj@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huawei.com \
--cc=clrkwllms@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=llong@redhat.com \
--cc=mkoutny@suse.com \
--cc=piliu@redhat.com \
--cc=rostedt@goodmis.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