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@xxxxxxxxx> > > 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. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
