On Wed, Feb 08, 2023 at 09:46:30PM +0100, Thomas Gleixner wrote: > On Wed, Feb 08 2023 at 10:15, Vlastimil Babka wrote: > > Cc+ Willy > > > On 2/7/23 19:20, Thomas Gleixner wrote: > >> On Tue, Feb 07 2023 at 15:47, Vlastimil Babka wrote: > >>> From 340d7c7b99f3e67780f6dec480ed1d27e6f325eb Mon Sep 17 00:00:00 2001 > >>> From: Vlastimil Babka <vbabka@xxxxxxx> > >>> Date: Tue, 7 Feb 2023 15:34:53 +0100 > >>> Subject: [PATCH] mm, slab/slub: remove notes that bulk alloc/free needs > >>> interrupts enabled > >>> > >>> The slab functions kmem_cache_[alloc|free]_bulk() have been documented > >>> as requiring interrupts to be enabled, since their addition in 2015. > >>> It's unclear whether that was a fundamental restriction, or an attempt > >>> to save some cpu cycles by not having to save and restore the irq > >>> flags. > >> > >> I don't think so. The restriction is rather meant to avoid huge > >> allocations in atomic context which causes latencies and also might > >> deplete the atomic reserves. > > > > Fair enough. > > > >> So I rather avoid that and enforce !ATOMIC mode despite the > >> local_irq_save/restore() change which is really only to accomodate with > >> early boot. > > > > We could add some warning then? People might use the bulk alloc unknowingly > > again e.g. via maple tree. GFP_KERNEL would warn through the existing > > warning, but e.g. GFP_ATOMIC currently not. > > Correct. > > > Some maple tree users could use its preallocation instead outside of the > > atomic context, when possible. > > Right. > > The issue is that there might be maple_tree users which depend on > GFP_ATOMIC, but call in from interrupt enabled context, which is > legitimate today. > > Willy might have some insight on that. Not today, but eventually. There are XArray users which modify the tree in interrupt context or under some other spinlock that we can't drop for them in order to do an allocation. And I want to replace the radix tree underpinnings of the XArray with the maple tree. In my copious spare time.
