All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	"joel@joelfernandes.org George Spelvin" <lkml@sdf.org>,
	rcu@vger.kernel.org, josh@joshtriplett.org, rostedt@goodmis.org,
	mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com
Subject: Re: Is there a reason we don't have kvfree_rcu()?
Date: Thu, 12 Mar 2020 23:58:09 -0400	[thread overview]
Message-ID: <20200313035809.GC190951@google.com> (raw)
In-Reply-To: <20200312191009.GA27429@pc636>

On Thu, Mar 12, 2020 at 08:10:09PM +0100, Uladzislau Rezki wrote:
> On Thu, Mar 12, 2020 at 11:11:38AM -0700, Paul E. McKenney wrote:
> > On Thu, Mar 12, 2020 at 04:27:30PM +0000, George Spelvin wrote:
> > > kvfree() is a superset of kfree(), so there's nothing obvious stopping 
> > > kfree_rcu() from simply changing to kvfree() and everything will keep 
> > > working.
> > > 
> > > I'd probably add a kvfree_rcu() alias, just for documentation's sake and
> > > to make code that depends on the new feature explode at compile time, but
> > > it could be identical behind the scenes.
> > > 
> > > There's an existing user in mm/list_lru.c already.
> > > 
> > > I was just thinking of using kvmalloc() in a module, and realized that the 
> > > lack of a core kvfree_rcu() helper meant I'd have to synchronize_rcu() on 
> > > module unload.
> > 
> > There was a recent proposal to do just that, but current patches in -rcu
> > use kfree_bulk().  It doesn't look to me that this works for kfvree()
> > under the covers in its current form.  Could it be upgraded to handle
> > this case?
> > 
> > Adding Vlad on CC for his thoughts.
> > 
> Paul, see below my view:
> 
> Answering to topic's question it looks like we need kvfree_rcu() support :)
> 
> It is easy to add it actually. But if we are talking about the case when
> an object has rcu_head inside. From the other hand recent discussion showed
> that we would like to have head-less variant of the kvfree_rcu() functionality:
> 
> https://lkml.org/lkml/2020/2/18/566
> 
> for example, as Ted pointed, he would go with head-less case(for ext4) only.
> The reason is nobody wants to modify internal structures injecting rcu_head
> there. Also there are many other places in the kernel where it would be good
> to have kfree_rcu() head-less variant as well.
> 
> I spent some time implementing it together with Joel. It is ready from my
> side but only for RCU-tree case. Next step is RCU-tiny support, so i am
> working on it.  
> 
> I can send out an RFC for RCU-tree only support, so we can discuss it
> and agree on how to move forward. After that i or Joel or together can
> update RCU-tine.
> 
> Joel: What do you think?

Yes, your sending an RFC with what you have sounds good. I can prepare a tree
for both of us then and we can develop on that. I was actually waiting on
your patches so I can add more on top.

One more thing I want to add is the shrinker interface to prevent OOM during
kfree_rcu() flood. I sent patches to fix that. It works well. We can prepare
a tree with all these features and develop on that so there's no conflict.

For -tiny and lack of rcu_head, I think we discussed that we would
always dynamically allocate rcu_head for that case.

> Another thought. We can add kvfree_rcu(ptr, rcu) first, because it is
> easy and after that implement head-less case.

Yes, that is also fine. We can start simple and then keep improving it. I
think we have now 3 users who want head-less interface so ultimately we can
shoot for that goal (at later stage).

thanks,

 - Joel


  reply	other threads:[~2020-03-13  3:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12 16:27 Is there a reason we don't have kvfree_rcu()? George Spelvin
2020-03-12 18:11 ` Paul E. McKenney
2020-03-12 19:10   ` Uladzislau Rezki
2020-03-13  3:58     ` Joel Fernandes [this message]
2020-03-13 13:21       ` Uladzislau Rezki
2020-03-13 13:40         ` Joel Fernandes
2020-03-13  5:06     ` George Spelvin
2020-03-13 13:44       ` Uladzislau Rezki
2020-03-13 13:54       ` Paul E. McKenney
2020-03-13 16:52         ` George Spelvin
2020-03-13 18:19           ` Paul E. McKenney
2020-03-13 18:46             ` George Spelvin
2020-03-13 19:58               ` Paul E. McKenney
2020-03-12 22:24   ` George Spelvin

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=20200313035809.GC190951@google.com \
    --to=joel@joelfernandes.org \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=lkml@sdf.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=urezki@gmail.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.