[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1601271047480.14468@east.gentwo.org>
Date: Wed, 27 Jan 2016 10:48:47 -0600 (CST)
From: Christoph Lameter <cl@...ux.com>
To: Vlastimil Babka <vbabka@...e.cz>
cc: Joonsoo Kim <js1304@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 16/16] mm/slab: introduce new slab management type,
OBJFREELIST_SLAB
On Wed, 27 Jan 2016, Vlastimil Babka wrote:
> On 01/14/2016 06:24 AM, Joonsoo Kim wrote:
> > In fact, I tested another idea implementing OBJFREELIST_SLAB with
> > extendable linked array through another freed object. It can remove
> > memory waste completely but it causes more computational overhead
> > in critical lock path and it seems that overhead outweigh benefit.
> > So, this patch doesn't include it.
>
> Can you elaborate? Do we actually need an extendable linked array? Why not just
> store the pointer to the next free object into the object, NULL for the last
> one? I.e. a singly-linked list. We should never need to actually traverse it?
>
> freeing object obj:
> *obj = page->freelist;
> page->freelist = obj;
>
> allocating object:
> obj = page->freelist;
> page->freelist = *obj;
> *obj = NULL;
Well the single linked lists are a concept of another slab allocator. At
what point do we rename SLAB to SLUB2?
Powered by blists - more mailing lists