All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Uladzislau Rezki <urezki@gmail.com>,
	linux-mm@kvack.org, "Paul E . McKenney" <paulmck@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	RCU <rcu@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>
Subject: Re: [PATCH v2 0/5] Move kvfree_rcu() into SLAB (v2)
Date: Mon, 16 Dec 2024 16:41:35 +0100	[thread overview]
Message-ID: <Z2BKLzOGv_Ki_7fj@pc636> (raw)
In-Reply-To: <d352db4f-4bb8-4300-b235-bbd1bdb3aa21@suse.cz>

On Mon, Dec 16, 2024 at 03:20:44PM +0100, Vlastimil Babka wrote:
> On 12/16/24 12:03, Uladzislau Rezki wrote:
> > On Sun, Dec 15, 2024 at 06:30:02PM +0100, Vlastimil Babka wrote:
> >> On 12/12/24 19:02, Uladzislau Rezki (Sony) wrote:
> >> > Hello!
> >> > 
> >> > This is v2. It is based on the Linux 6.13-rc2. The first version is
> >> > here:
> >> > 
> >> > https://lore.kernel.org/linux-mm/20241210164035.3391747-4-urezki@gmail.com/T/
> >> > 
> >> > The difference between v1 and v2 is that, the preparation process is
> >> > done in original place instead and after that there is one final move.
> >> 
> >> Looks good, will include in slab/for-next
> >> 
> >> I think patch 5 should add more explanation to the commit message - the
> >> subthread started by Christoph could provide content :) Can you summarize so
> >> I can amend the commit log?
> >> 
> > I will :)
> > 
> >> Also how about a followup patch moving the rcu-tiny implementation of
> >> kvfree_call_rcu()?
> >> 
> > As, Paul already noted, it would make sense. Or just remove a tiny
> > implementation.
> 
> AFAICS tiny rcu is for !SMP systems. Do they benefit from the "full"
> implementation with all the batching etc or would that be unnecessary overhead?
> 
Yes, it is for a really small systems with low amount of memory. I see
only one overhead it is about driving objects in pages. For a small
system it can be critical because we allocate.

From the other hand, for a tiny variant we can modify the normal variant
by bypassing batching logic, thus do not consume memory(for Tiny case)
i.e. merge it to a normal kvfree_rcu() path.

After that we do not depend on CONFIG_RCU_TINY option. Probably we need
also to perform some adaptation of regular kvfree_rcu() for a single CPU
system.

--
Uladzislau Rezki

  reply	other threads:[~2024-12-16 15:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12 18:02 [PATCH v2 0/5] Move kvfree_rcu() into SLAB (v2) Uladzislau Rezki (Sony)
2024-12-12 18:02 ` [PATCH v2 1/5] rcu/kvfree: Initialize kvfree_rcu() separately Uladzislau Rezki (Sony)
2024-12-12 18:02 ` [PATCH v2 2/5] rcu/kvfree: Move some functions under CONFIG_TINY_RCU Uladzislau Rezki (Sony)
2024-12-12 18:02 ` [PATCH v2 3/5] rcu/kvfree: Adjust names passed into trace functions Uladzislau Rezki (Sony)
2024-12-12 18:02 ` [PATCH v2 4/5] rcu/kvfree: Adjust a shrinker name Uladzislau Rezki (Sony)
2024-12-12 18:02 ` [PATCH v2 5/5] mm/slab: Move kvfree_rcu() into SLAB Uladzislau Rezki (Sony)
2024-12-12 18:30 ` [PATCH v2 0/5] Move kvfree_rcu() into SLAB (v2) Christoph Lameter (Ampere)
2024-12-12 19:08   ` Uladzislau Rezki
2024-12-12 19:10   ` Paul E. McKenney
2024-12-12 19:13     ` Uladzislau Rezki
2024-12-15 17:30 ` Vlastimil Babka
2024-12-15 18:21   ` Paul E. McKenney
2024-12-16 11:03   ` Uladzislau Rezki
2024-12-16 14:20     ` Vlastimil Babka
2024-12-16 15:41       ` Uladzislau Rezki [this message]
2024-12-16 15:44         ` Vlastimil Babka
2024-12-16 15:55           ` Uladzislau Rezki
2024-12-16 16:46             ` Paul E. McKenney
2025-01-20 22:06               ` Vlastimil Babka
2025-01-21 13:33                 ` Uladzislau Rezki
2025-01-21 13:49                   ` Vlastimil Babka
2025-01-21 14:14                     ` Uladzislau Rezki
2025-01-21 20:32                       ` Paul E. McKenney
2025-01-22 15:04                         ` Joel Fernandes
2025-01-22 16:43                           ` Vlastimil Babka
2025-01-22 16:47                             ` Joel Fernandes
2025-01-22 17:42                             ` Uladzislau Rezki
2024-12-16 13:07   ` Uladzislau Rezki
2025-01-11 19:40     ` Vlastimil Babka
2025-01-06  7:21 ` [External Mail] " Hyeonggon Yoo
2025-01-11 19:43   ` Vlastimil Babka

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=Z2BKLzOGv_Ki_7fj@pc636 \
    --to=urezki@gmail.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleksiy.avramchenko@sony.com \
    --cc=paulmck@kernel.org \
    --cc=penberg@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    /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.