From: "Paul E. McKenney" <paulmck@kernel.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: linux-mm@kvack.org, Matthew Wilcox <willy@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Theodore Y . Ts'o" <tytso@mit.edu>,
Joel Fernandes <joel@joelfernandes.org>,
RCU <rcu@vger.kernel.org>,
Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Subject: Re: [PATCH v2 09/16] rcu/tree: Maintain separate array for vmalloc ptrs
Date: Mon, 22 Jun 2020 12:53:29 -0700 [thread overview]
Message-ID: <20200622195329.GN9247@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20200622190406.GA3787@pc636>
On Mon, Jun 22, 2020 at 09:04:06PM +0200, Uladzislau Rezki wrote:
> > > >
> > > > Very good. When does kfree_rcu() and friends move out of kernel/rcu?
> > > >
> > > Do you mean to move the whole logic of kfree_rcu() from top to down to mm/?
> >
> > I do mean exactly that.
> >
> > That was my goal some years back when Rao Shoaib was making the first
> > attempt along these lines, and it remains my goal. After all, if this
> > effort is at all successful, the coupling between kfree_rcu() with
> > slab/slob/slub will become much tighter than that between kfree_rcu()
> > and RCU.
> >
> > There will need to be some additional RCU APIs used by kfree_rcu(),
> > for example, something to tell RCU how many blocks are awaiting a
> > grace period. But these are narrow and easily defined APIs.
> >
> I also think that k[v]free_rcu() should reside somewhere under "mm/".
> Currently they are defined as macros under "linux/rcupdate.h". So i
> am not sure if definitions should stay there or moved also.
I am not as worried about the high-level macros as I am about the code
that does the bulk of the work, but they should still move as well.
Otherwise, changes involving both the macros and the underlying
implementation are harder than needed.
> Implementation of the k[v]free_rcu() is under rcu/tree.c and for tiny
> variant is under rcutiny.h. It can be moved to the mm/slab_common.c
> or independent files can be created. I think, mm people should consult
> what is the best way to go :)
>
> Any thoughts on it?
I don't have any opinion on exactly where in mm the underlying
implementation code should go. You suggestion of mm/slab_common.c
seems fine to me. ;-)
Thanx, Paul
next prev parent reply other threads:[~2020-06-22 19:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 21:47 [PATCH v2 00/16] Introduce kvfree_rcu(1 or 2 arguments) Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 01/16] rcu/tree: Keep kfree_rcu() awake during lock contention Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 02/16] rcu/tree: Skip entry into the page allocator for PREEMPT_RT Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 03/16] rcu/tree: Repeat the monitor if any free channel is busy Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 04/16] rcu/tree: Make debug_objects logic independent of rcu_head Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 05/16] rcu/tree: Simplify KFREE_BULK_MAX_ENTR macro Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 06/16] rcu/tree: Move kfree_rcu_cpu locking/unlocking to separate functions Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 07/16] rcu/tree: Use static initializer for krc.lock Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 08/16] rcu/tree: cache specified number of objects Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 09/16] rcu/tree: Maintain separate array for vmalloc ptrs Uladzislau Rezki (Sony)
2020-06-17 23:46 ` Paul E. McKenney
2020-06-18 0:52 ` Matthew Wilcox
2020-06-18 3:18 ` Paul E. McKenney
2020-06-18 17:35 ` Uladzislau Rezki
2020-06-18 17:57 ` Paul E. McKenney
2020-06-18 18:34 ` Uladzislau Rezki
2020-06-18 19:03 ` Paul E. McKenney
2020-06-18 20:35 ` Uladzislau Rezki
2020-06-18 20:38 ` Matthew Wilcox
2020-06-18 21:17 ` Uladzislau Rezki
2020-06-18 21:34 ` Paul E. McKenney
2020-06-19 15:46 ` Uladzislau Rezki
2020-06-19 16:25 ` Paul E. McKenney
2020-06-22 19:04 ` Uladzislau Rezki
2020-06-22 19:53 ` Paul E. McKenney [this message]
2020-06-30 17:46 ` Uladzislau Rezki
2020-06-18 17:30 ` Uladzislau Rezki
2020-06-18 17:35 ` Matthew Wilcox
2020-06-18 20:03 ` Uladzislau Rezki
2020-06-18 17:25 ` Uladzislau Rezki
2020-06-18 17:32 ` Paul E. McKenney
2020-06-18 17:56 ` Uladzislau Rezki
2020-06-18 18:15 ` Matthew Wilcox
2020-06-18 18:23 ` Uladzislau Rezki
2020-06-18 18:37 ` Matthew Wilcox
2020-06-18 18:48 ` Uladzislau Rezki
2020-05-25 21:47 ` [PATCH v2 10/16] rcu/tiny: support vmalloc in tiny-RCU Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 11/16] rcu: Rename *_kfree_callback/*_kfree_rcu_offset/kfree_call_* Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 12/16] mm/list_lru.c: Rename kvfree_rcu() to local variant Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 13/16] rcu: Introduce 2 arg kvfree_rcu() interface Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 14/16] rcu: Support reclaim for head-less object Uladzislau Rezki (Sony)
2020-05-25 21:47 ` [PATCH v2 15/16] rcu: Introduce single argument kvfree_rcu() interface Uladzislau Rezki (Sony)
2020-05-25 21:48 ` [PATCH v2 16/16] lib/test_vmalloc.c: Add test cases for kvfree_rcu() Uladzislau Rezki (Sony)
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=20200622195329.GN9247@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oleksiy.avramchenko@sonymobile.com \
--cc=rcu@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=urezki@gmail.com \
--cc=willy@infradead.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).