Messages in this thread |  | | | Date | Wed, 21 Oct 2009 23:20:34 +0200 | | From | Karol Lewandowski <> | | Subject | Re: [PATCH] SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() (was: Re: [Bug #14265] ifconfig: page allocation failure. order:5,ode:0x8020 w/ e100) |
| |
On Wed, Oct 21, 2009 at 02:06:41PM -0700, David Rientjes wrote: > On Wed, 21 Oct 2009, Karol Lewandowski wrote: > > > commit d6849591e042bceb66f1b4513a1df6740d2ad762 > > Author: Karol Lewandowski <karol.k.lewandowski@gmail.com> > > Date: Wed Oct 21 21:01:20 2009 +0200 > > > > SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() > > > > Commit ba52270d18fb17ce2cf176b35419dab1e43fe4a3 unconditionally > > cleared __GFP_NOFAIL flag on all allocations. > > > > No, it clears __GFP_NOFAIL from the first allocation of oo_order(s->oo). > If that fails (and it's easy to fail, it has __GFP_NORETRY), another > allocation is attempted with oo_order(s->min), for which __GFP_NOFAIL > would be preserved if that's the slab cache's allocflags.
Right, patch is junk.
However, I haven't been able to trigger failures since I've switched to SLAB allocator. That patch seemed related (and wrong), but it wasn't.
> > */ > > - page = alloc_slab_page(flags, node, oo); > > + page = alloc_slab_page(flags | nofail, node, oo); > > if (!page) > > return NULL; > > > > > > This does nothing. You may have missed that the lower order allocation is > passing 'flags' (which is a union of the gfp flags passed to > allocate_slab() based on the allocation context and the cache's > allocflags), and not alloc_gfp where __GFP_NOFAIL is masked.
Right, I missed that.
> Nack. > > Note: slub isn't going to be a culprit in order 5 allocation failures > since they have kmalloc passthrough to the page allocator.
However, it might change fragmentation somewhat I guess. This might make problem more/less visible.
|  |