On Wed, 18 Apr 2018, Mikulas Patocka wrote: > > Mikulas Patoka wants to ensure that no fallback to lower order happens. I > > think __GFP_NORETRY should work correctly in that case too and not fall > > back. > > > > > > > > Allocating at a smaller order is a retry operation and should not > > be attempted. > > > > If the caller does not want retries then respect that. > > > > GFP_NORETRY allows callers to ensure that only maximum order > > allocations are attempted. > > > > Signed-off-by: Christoph Lameter <cl@xxxxxxxxx> > > > > Index: linux/mm/slub.c > > =================================================================== > > --- linux.orig/mm/slub.c > > +++ linux/mm/slub.c > > @@ -1598,7 +1598,7 @@ static struct page *allocate_slab(struct > > alloc_gfp = (alloc_gfp | __GFP_NOMEMALLOC) & ~(__GFP_RECLAIM|__GFP_NOFAIL); > > > > page = alloc_slab_page(s, alloc_gfp, node, oo); > > - if (unlikely(!page)) { > > + if (unlikely(!page) && !(flags & __GFP_NORETRY)) { > > oo = s->min; > > alloc_gfp = flags; > > /* > > No, this would hit NULL pointer dereference if page is NULL and > __GFP_NORETRY is set. You want this: > > --- > mm/slub.c | 2 ++ > 1 file changed, 2 insertions(+) > > Index: linux-2.6/mm/slub.c > =================================================================== > --- linux-2.6.orig/mm/slub.c 2018-04-17 20:58:23.000000000 +0200 > +++ linux-2.6/mm/slub.c 2018-04-18 17:04:01.000000000 +0200 > @@ -1599,6 +1599,8 @@ static struct page *allocate_slab(struct > > page = alloc_slab_page(s, alloc_gfp, node, oo); > if (unlikely(!page)) { > + if (flags & __GFP_NORETRY) > + goto out; > oo = s->min; > alloc_gfp = flags; > /* > I don't see the connection between the max order, which can be influenced by userspace with slub_min_objects, slub_min_order, etc, and specifying __GFP_NORETRY which means try to reclaim and free memory but don't loop. If I force a slab cache to try a max order of 9 for hugepages as a best effort, why does __GFP_NORETRY suddenly mean I won't fallback to oo_order(s->min)? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel