From: Christoph Lameter <cl@linux.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
Matt Mackall <mpm@selenic.com>,
Glauber Costa <glommer@parallels.com>,
Joonsoo Kim <js1304@gmail.com>
Subject: Common 00/22] Sl[auo]b: Common functionality V3
Date: Wed, 23 May 2012 15:34:33 -0500 [thread overview]
Message-ID: <20120523203433.340661918@linux.com> (raw)
V2->V3:
- Incorporate more feedback from Joonsoo Kim and Glauber Costa
- And a couple more patches to deal with slab duping and move
more code to slab_common.c
V1->V2:
- Incorporate glommers feedback.
- Add 2 more patches dealing with common code in kmem_cache_destroy
This is a series of patches that extracts common functionality from
slab allocators into a common code base. The intend is to standardize
as much as possible of the allocator behavior while keeping the
distinctive features of each allocator which are mostly due to their
storage format and serialization approaches.
This patchset makes a beginning by extracting common functionality in
kmem_cache_create() and kmem_cache_destroy(). However, there are
numerous other areas where such work could be beneficial:
1. Extract the sysfs support from SLUB and make it common. That way
all allocators have a common sysfs API and are handleable in the same
way regardless of the allocator chose.
2. Extract the error reporting and checking from SLUB and make
it available for all allocators. This means that all allocators
will gain the resiliency and error handling capabilties.
3. Extract the memory hotplug and cpu hotplug handling. It seems that
SLAB may be more sophisticated here. Having common code here will
make it easier to maintain the special code.
4. Extract the aliasing capability of SLUB. This will enable fast
slab creation without creating too many additional slab caches.
The arrays of caches of varying sizes in numerous subsystems
do not cause the creation of numerous slab caches. Storage
density is increased and the cache footprint is reduced.
Ultimately it is to be hoped that the special code for each allocator
shrinks to a mininum. This will also make it easier to make modification
to allocators.
In the far future one could envision that the current allocators will
just become storage algorithms that can be chosen based on the need of
the subsystem. F.e.
Cpu cache dependend performance = Bonwick allocator (SLAB)
Minimal cycle count and cache footprint = SLUB
Maximum storage density = K&R allocator (SLOB)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2012-05-23 20:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-23 20:34 Christoph Lameter [this message]
2012-05-23 20:34 ` Common 01/22] [slob] Define page struct fields used in mm_types.h Christoph Lameter
2012-05-31 21:14 ` David Rientjes
2012-06-01 13:30 ` JoonSoo Kim
2012-05-23 20:34 ` Common 03/22] [slob] Remove various small accessors Christoph Lameter
2012-05-31 21:19 ` David Rientjes
2012-06-01 13:29 ` JoonSoo Kim
2012-05-23 20:34 ` Common 05/22] [slab] Remove some accessors Christoph Lameter
2012-05-23 20:34 ` Common 06/22] Extract common fields from struct kmem_cache Christoph Lameter
2012-05-30 6:39 ` Pekka Enberg
2012-05-30 15:29 ` Christoph Lameter
2012-05-30 18:10 ` Christoph Lameter
2012-05-31 7:52 ` Pekka Enberg
2012-05-23 20:34 ` Common 07/22] Extract common code for kmem_cache_create() Christoph Lameter
2012-05-23 20:34 ` Common 08/22] Common definition for boot state of the slab allocators Christoph Lameter
2012-05-23 20:34 ` Common 09/22] Use a common mutex definition Christoph Lameter
2012-05-23 20:34 ` Common 10/22] Move kmem_cache_create mutex handling to common code Christoph Lameter
2012-05-23 20:34 ` Common 12/22] Extract a common function for kmem_cache_destroy Christoph Lameter
2012-05-23 20:34 ` Common 13/22] Always use the name "kmem_cache" for the slab cache with the kmem_cache structure Christoph Lameter
2012-05-23 20:34 ` Common 15/22] Get rid of __kmem_cache_destroy Christoph Lameter
2012-05-23 20:34 ` Common 16/22] Move duping of slab name to slab_common.c Christoph Lameter
2012-05-23 20:34 ` Common 17/22] Do slab aliasing call from common code Christoph Lameter
2012-05-23 20:34 ` Common 19/22] Do not pass ctor to __kmem_cache_create() Christoph Lameter
2012-05-23 20:34 ` Common 20/22] Set parameters on kmem_cache instead of passing them to functions Christoph Lameter
2012-05-23 20:34 ` Common 21/22] Common alignment code Christoph Lameter
2012-05-23 20:34 ` Common 22/22] Common object size alignment Christoph Lameter
2012-05-30 6:28 ` Common 00/22] Sl[auo]b: Common functionality V3 Pekka Enberg
[not found] ` <20120523203506.170219003@linux.com>
2012-05-31 21:15 ` Common 02/22] [slob] No need to zero mapping since it is no longer in use David Rientjes
2012-06-01 13:30 ` JoonSoo Kim
[not found] ` <20120523203507.324764286@linux.com>
2012-05-31 21:23 ` Common 04/22] [slab] Use page struct fields instead of casting David Rientjes
2012-06-01 13:17 ` JoonSoo Kim
2012-06-01 14:00 ` 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=20120523203433.340661918@linux.com \
--to=cl@linux.com \
--cc=glommer@parallels.com \
--cc=js1304@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.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;
as well as URLs for NNTP newsgroup(s).