linux-kernel - Re: [PATCH 1/4] rcu/kvfree: Support dynamic rcu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zs9Xm6VKcpMkWbLE@pc636>
Date: Wed, 28 Aug 2024 19:00:11 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: "Uladzislau Rezki (Sony)" <urezki@...il.com>,
	"Paul E . McKenney" <paulmck@...nel.org>, RCU <rcu@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Neeraj upadhyay <Neeraj.Upadhyay@....com>,
	Boqun Feng <boqun.feng@...il.com>,
	Joel Fernandes <joel@...lfernandes.org>,
	Frederic Weisbecker <frederic@...nel.org>,
	Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>
Subject: Re: [PATCH 1/4] rcu/kvfree: Support dynamic rcu_head for single
 argument objects

On Wed, Aug 28, 2024 at 04:58:48PM +0200, Vlastimil Babka wrote:
> On 8/28/24 13:09, Uladzislau Rezki (Sony) wrote:
> > Add a support of dynamically attaching an rcu_head to an object
> > which gets freed via the single argument of kvfree_rcu(). This is
> > used in the path, when a page allocation fails due to a high memory
> > pressure.
> > 
> > The basic idea behind of this is to minimize a hit of slow path
> > which requires a caller to wait until a grace period is passed.
> > 
> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> 
> So IIUC it's a situation where we can't allocate a page, but we hope the
> kmalloc-32 slab has still free objects to give us dyn_rcu_head's before it
> would have to also make a page allocation?
> 
Yes, you understood it correctly :)

>
> So that may really be possible and there might potentially be many such
> objects, but I wonder if there's really a benefit. The system is struggling
> for memory and the single-argument caller specifically is _mightsleep so it
> could e.g. instead go direct reclaim a page rather than start depleting the
> kmalloc-32 slab, no?
> 
This is a good question about benefit and i need to say that i do not
have a strong opinion here. I post this patch to get some opinions about
it. This "dynamic attaching" we discussed with RCU folk a few years ago
and decided not to go with it. I have not found an information why.

The page request path, which is "normal/fast", can lead to a "light"
direct reclaim, if still fails, then we are in a high pressure situation.
Depleting a slab is probably not worth it, especially that the patch in
this series:

[PATCH 4/4] rcu/kvfree: Switch to expedited version in slow path

switches to more faster synchronize_rcu() version to speedup a reclaim.

+ this [PATCH 3/4] rcu/kvfree: Use polled API in a slow path
which also improves a slow path in terms of that a GP might be already
passed for the object being freed.

I am totally OK to drop this patch. This is fine to me.

--
Uladzislau Rezki