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. Some maple tree users could use its preallocation instead outside of the atomic context, when possible. > Thanks, > > tglx
