Messages in this thread | | | Date | Wed, 20 Jul 2011 17:28:10 +0400 | From | Konstantin Khlebnikov <> | Subject | Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT |
| |
Pekka Enberg wrote: > On Wed, 20 Jul 2011, Konstantin Khlebnikov wrote: >> Order of sizeof(struct kmem_cache) can be bigger than PAGE_ALLOC_COSTLY_ORDER, >> thus there is a good chance of unsuccessful allocation. >> With __GFP_REPEAT buddy-allocator will reclaim/compact memory more aggressively. >> >> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org> >> --- >> mm/slab.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/mm/slab.c b/mm/slab.c >> index d96e223..53bddc8 100644 >> --- a/mm/slab.c >> +++ b/mm/slab.c >> @@ -2304,7 +2304,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, >> gfp = GFP_NOWAIT; >> >> /* Get cache's description obj. */ >> - cachep = kmem_cache_zalloc(&cache_cache, gfp); >> + cachep = kmem_cache_zalloc(&cache_cache, gfp | __GFP_REPEAT); >> if (!cachep) >> goto oops; > > The changelog isn't that convincing, really. This is kmem_cache_create() > so I'm surprised we'd ever get NULL here in practice. Does this fix some > problem you're seeing? If this is really an issue, I'd blame the page > allocator as GFP_KERNEL should just work.
nf_conntrack creates separate slab-cache for each net-namespace, this patch of course not eliminates the chance of failure, but makes it more acceptable.
struct kmem_size for slub is more compact, it uses pecpu-pointers instead of dumb NR_CPUS-size array. probably better to fix this side...
> > Pekka
| |