On Wed, 16 Jan 2013, Liu Bo wrote:
> --- a/include/linux/slub_def.h
> +++ b/include/linux/slub_def.h
> @@ -93,6 +93,7 @@ struct kmem_cache {
> gfp_t allocflags; /* gfp flags to use on each alloc */
> int refcount; /* Refcount for slab cache destroy */
> void (*cto
On Mon, 14 Jan 2013, Liu Bo wrote:
> This adds a leak decoder callback so that kmem_cache_destroy()
> can use to generate debugging output for the allocated objects.
Interesting idea.
> @@ -3787,6 +3789,9 @@ static int slab_unmergeable(struct kmem_cache *s)
> if (s->ctor)
> r
On Wed, 25 Aug 2010, David Rientjes wrote:
> Because we can remove the flag, remove branches from the page allocator
> slowpath, and none of these allocations actually are dependent on
> __GFP_NOFAIL since they are all under PAGE_ALLOC_COSTLY_ORDER.
Then we can simply remove __GFP_NOFAIL? Functio
On Wed, 25 Aug 2010, David Rientjes wrote:
> On Wed, 25 Aug 2010, Christoph Lameter wrote:
>
> > If the higher order fails in slub then an order 0 alloc is attempted
> > without __GFP_NORETRY. In both cases the nofail behavior of the page
> > allocator determines the o
On Wed, 25 Aug 2010, David Rientjes wrote:
> It all depends on what flags are passed to kmalloc(), slab nor slub
> enforce __GFP_NOFAIL behavior themselves. In slab, cache_grow() will
> return NULL depending on whether the page allocator returns NULL, and that
> would only happen for __GFP_NORETR
We already have __GFP_NOFAIL behavior for slab allocations since
a __GFP_NOFAIL flag is passed through to the page allocator if no objects
are available.
The page allocator will do the same as when called directly with
__GFP_NOFAIL and so we have consistent behavior regardless of the
allocator use
