From: Richard Kennedy <richard@rsk.demon.co.uk>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Rientjes <rientjes@google.com>, Mel Gorman <mel@csn.ul.ie>,
npiggin@kernel.dk, yanmin_zhang@linux.intel.com
Subject: Re: [UnifiedV4 00/16] The Unified slab allocator (V4)
Date: Wed, 06 Oct 2010 12:03:27 +0100 [thread overview]
Message-ID: <4CAC577F.9040401@rsk.demon.co.uk> (raw)
In-Reply-To: <AANLkTinPU4T59PvDH1wX2Rcy7beL=TvmHOZh_wWuBU-T@mail.gmail.com>
On 06/10/10 09:01, Pekka Enberg wrote:
> (Adding more people who've taken interest in slab performance in the
> past to CC.)
>
> On Tue, Oct 5, 2010 at 9:57 PM, Christoph Lameter <cl@linux.com> wrote:
>> V3->V4:
>> - Lots of debugging
>> - Performance optimizations (more would be good)...
>> - Drop per slab locking in favor of per node locking for
>> partial lists (queuing implies freeing large amounts of objects
>> to per node lists of slab).
>> - Implement object expiration via reclaim VM logic.
>>
>> The following is a release of an allocator based on SLAB
>> and SLUB that integrates the best approaches from both allocators. The
>> per cpu queuing is like in SLAB whereas much of the infrastructure
>> comes from SLUB.
>>
>> After this patches SLUB will track the cpu cache contents
>> like SLAB attemped to. There are a number of architectural differences:
>>
>> 1. SLUB accurately tracks cpu caches instead of assuming that there
>> is only a single cpu cache per node or system.
>>
>> 2. SLUB object expiration is tied into the page reclaim logic. There
>> is no periodic cache expiration.
>>
>> 3. SLUB caches are dynamically configurable via the sysfs filesystem.
>>
>> 4. There is no per slab page metadata structure to maintain (aside
>> from the object bitmap that usually fits into the page struct).
>>
>> 5. Has all the resiliency and diagnostic features of SLUB.
>>
>> The unified allocator is a merging of SLUB with some queuing concepts from
>> SLAB and a new way of managing objects in the slabs using bitmaps. Memory
>> wise this is slightly more inefficient than SLUB (due to the need to place
>> large bitmaps --sized a few words--in some slab pages if there are more
>> than BITS_PER_LONG objects in a slab) but in general does not increase space
>> use too much.
>>
>> The SLAB scheme of not touching the object during management is adopted.
>> The unified allocator can efficiently free and allocate cache cold objects
>> without causing cache misses.
>>
Hi Christoph,
What tree are these patches against ? I'm getting patch failures on the
main tree.
regards
Richard
next prev parent reply other threads:[~2010-10-06 11:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-05 18:57 Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 01/16] slub: Enable sysfs support for !CONFIG_SLUB_DEBUG Christoph Lameter
2010-10-06 14:02 ` Pekka Enberg
2010-10-05 18:57 ` [UnifiedV4 02/16] slub: Move functions to reduce #ifdefs Christoph Lameter
2010-10-06 14:02 ` Pekka Enberg
2010-10-05 18:57 ` [UnifiedV4 03/16] slub: Add per cpu queueing Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 04/16] slub: Allow resizing of per cpu queues Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 05/16] slub: Remove MAX_OBJS limitation Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 06/16] slub: Drop allocator announcement Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 07/16] slub: Object based NUMA policies Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 08/16] slub: Get rid of page lock and rely on per node lock Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 09/16] slub: Shared cache to exploit cross cpu caching abilities Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 10/16] slub: Support Alien Caches Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 11/16] slub: Add a "touched" state to queues and partial lists Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 12/16] slub: Cached object expiration Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 13/16] vmscan: Tie slub object expiration into page reclaim Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 14/16] slub: Reduce size of not performance critical slabs Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 15/16] slub: Detailed reports on validate Christoph Lameter
2010-10-05 18:57 ` [UnifiedV4 16/16] slub: Add stats for alien allocation slowpath Christoph Lameter
2010-10-06 8:01 ` [UnifiedV4 00/16] The Unified slab allocator (V4) Pekka Enberg
2010-10-06 11:03 ` Richard Kennedy [this message]
2010-10-06 11:19 ` Pekka Enberg
2010-10-06 15:46 ` Richard Kennedy
2010-10-06 16:21 ` [UnifiedV4 slabinfo 1/2] Move slabinfo.c to tools/slub/slabinfo.c Christoph Lameter
2010-10-06 16:21 ` [UnifiedV4 slabinfo 2/2] slub: update slabinfo.c for queuing Christoph Lameter
2010-10-06 20:56 ` [UnifiedV4 00/16] The Unified slab allocator (V4) Christoph Lameter
2010-10-06 16:00 ` Christoph Lameter
2010-10-06 12:37 ` Wu Fengguang
2010-10-13 2:21 ` Alex,Shi
2010-10-18 18:00 ` Christoph Lameter
2010-10-19 0:01 ` Alex,Shi
2010-10-06 15:56 ` Christoph Lameter
2010-10-13 14:14 ` Mel Gorman
2010-10-18 18:13 ` Christoph Lameter
2010-10-19 9:23 ` Mel Gorman
2010-10-12 18:25 ` Mel Gorman
2010-10-13 7:16 ` Pekka Enberg
2010-10-13 13:46 ` Mel Gorman
2010-10-13 16:10 ` Christoph Lameter
2010-10-19 20:39 ` David Rientjes
2010-10-20 13:47 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CAC577F.9040401@rsk.demon.co.uk \
--to=richard@rsk.demon.co.uk \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=npiggin@kernel.dk \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=yanmin_zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome