Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- From: Christoph Lameter <clameter@xxxxxxx>
- Date: Fri, 9 Mar 2007 08:40:58 -0800 (PST)
On Fri, 9 Mar 2007, Mel Gorman wrote:
I'm not sure what you mean by per-order queues. The buddy allocator already
has per-order lists.
Somehow they do not seem to work right. SLAB (and now SLUB too) can avoid
(or defer) fragmentation by keeping its own queues.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [SLUB 0/3] SLUB: The unqueued slab allocator V4
- From: Christoph Lameter
- Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- From: Mel Gorman
- Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- From: Christoph Lameter
- Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- From: Mel Gorman
- Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- From: Christoph Lameter
- Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- From: Mel Gorman
- [SLUB 0/3] SLUB: The unqueued slab allocator V4
- Prev by Date: Re: [RFC][PATCH 1/7] Resource counters
- Next by Date: Re: [PATCH 1/2] eCryptfs: convert lookup_one_len() to lookup_one_len_nd()
- Previous by thread: Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- Next by thread: Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
- Index(es):
Relevant Pages
|