| Subject | Re: [PATCH 03/33] mm: slub: add knowledge of reserve pages | From | Peter Zijlstra <> | Date | Wed, 31 Oct 2007 11:42:38 +0100 |
| |
On Wed, 2007-10-31 at 14:37 +1100, Nick Piggin wrote: > On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote: > > Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation > > contexts that are entitled to it. > > > > Care is taken to only touch the SLUB slow path. > > > > This is done to ensure reserve pages don't leak out and get consumed. > > I think this is generally a good idea (to prevent slab allocators > from stealing reserve). However I naively think the implementation > is a bit overengineered and thus has a few holes. > > Humour me, what was the problem with failing the slab allocation > (actually, not fail but just call into the page allocator to do > correct waiting / reclaim) in the slowpath if the process fails the > watermark checks?
Ah, we actually need slabs below the watermarks. Its just that once I allocated those slabs using __GFP_MEMALLOC/PF_MEMALLOC I don't want allocation contexts that do not have rights to those pages to walk off with objects.
So, this generic reserve framework still uses the slab allocator to provide certain kind of objects (kmalloc, kmem_cache_alloc), it just separates those that are and are not entitled to the reserves. [unhandled content-type:application/pgp-signature] |