[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1804171453190.26973@file01.intranet.prod.int.rdu2.redhat.com>
Date: Tue, 17 Apr 2018 14:53:45 -0400 (EDT)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Christopher Lameter <cl@...ux.com>
cc: Vlastimil Babka <vbabka@...e.cz>,
Mike Snitzer <snitzer@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
Pekka Enberg <penberg@...nel.org>, linux-mm@...ck.org,
dm-devel@...hat.com, David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: slab: introduce the flag SLAB_MINIMIZE_WASTE
On Tue, 17 Apr 2018, Christopher Lameter wrote:
> On Mon, 16 Apr 2018, Mikulas Patocka wrote:
>
> > dm-bufio deals gracefully with allocation failure, because it preallocates
> > some buffers with vmalloc, but other subsystems may not deal with it and
> > they cound return ENOMEM randomly or misbehave in other ways. So, the
> > "SLAB_MINIMIZE_WASTE" flag is also saying that the allocation may fail and
> > the caller is prepared to deal with it.
> >
> > The slub subsystem does actual fallback to low-order when the allocation
> > fails (it allows different order for each slab in the same cache), but
> > slab doesn't fallback and you get NULL if higher-order allocation fails.
> > So, SLAB_MINIMIZE_WASTE is needed for slab because it will just randomly
> > fail with higher order.
>
> Fix Slab instead of adding a flag that is only useful for one allocator?
Slab assumes that all slabs have the same order, so it's not so easy to
fix it.
Mikulas
Powered by blists - more mailing lists