cgroups.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Tejun Heo <tj@kernel.org>
Cc: "Jemmy Wong" <jemmywong512@gmail.com>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Waiman Long" <longman@redhat.com>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/3] cgroup: Add lock guard support
Date: Mon, 23 Jun 2025 16:03:21 +0200	[thread overview]
Message-ID: <20250623140321.GA3372@cmpxchg.org> (raw)
In-Reply-To: <aFYeU_dL0VOvyeYs@slm.duckdns.org>

On Fri, Jun 20, 2025 at 04:52:03PM -1000, Tejun Heo wrote:
> On Fri, Jun 20, 2025 at 06:45:54PM +0800, Jemmy Wong wrote:
> ...
> > > Tejun:
> > >> There are no practical benefits to converting the code base at this point.
> > > 
> > > I'd expect future backports (into such code) to be more robust wrt
> > > pairing errors.
> > > At the same time this is also my biggest concern about this change, the
> > > wide-spread diff would make current backporting more difficult.  (But
> > > I'd counter argue that one should think forward here.)
> 
> Well, I'm not necessarily against it but I generally dislike wholesale
> cleanups which create big patch application boundaries. If there are enough
> practical benefits, sure, we should do it, but when it's things like this -
> maybe possibly it's a bit better in the long term - the calculus isn't clear
> cut. People can argue these things to high heavens on abstract grounds, but
> if you break it down to practical gains vs. costs, it's not a huge
> difference.
> 
> But, again, I'm not against it. Johannes, any second thoughts?

Yeah, letting the primitives get used organically in new code and
patches sounds better to me than retrofitting it into an existing
function graph that wasn't designed with these in mind.

  reply	other threads:[~2025-06-23 14:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-06 16:18 [PATCH v1 0/3] cgroup: Add lock guard support Jemmy Wong
2025-06-06 16:18 ` [PATCH v1 1/3] cgroup: add lock guard support for cgroup_muetx Jemmy Wong
2025-06-17  9:09   ` Michal Koutný
2025-06-06 16:18 ` [PATCH v1 2/3] cgroup: add lock guard support for css_set_lock and rcu Jemmy Wong
2025-06-17  9:09   ` Michal Koutný
2025-06-06 16:18 ` [PATCH v1 3/3] cgroup: add lock guard support for others Jemmy Wong
2025-06-07 10:50   ` kernel test robot
2025-06-08  8:52     ` Jemmy Wong
2025-06-17  9:10   ` Michal Koutný
2025-06-09 16:34 ` [PATCH v1 0/3] cgroup: Add lock guard support Tejun Heo
2025-06-17  9:08 ` Michal Koutný
2025-06-20 10:45   ` Jemmy Wong
2025-06-21  2:52     ` Tejun Heo
2025-06-23 14:03       ` Johannes Weiner [this message]
2025-06-30 17:39         ` Michal Koutný

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=20250623140321.GA3372@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=cgroups@vger.kernel.org \
    --cc=jemmywong512@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.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;
as well as URLs for NNTP newsgroup(s).