On Wed, Aug 28, 2024 at 07:00:11PM +0200, Uladzislau Rezki wrote: > 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@xxxxxxxxx> > > > > 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. If I remember correctly, I asked "How are you testing this?", which was then taken as a criticism rather than a question. ;-) No one has reported an OOM-related problem with the code in its current form, for what little that is worth. Thanx, Paul > 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
