Cpu alloc slub support V2: Replace percpu allocator in slub.c
Subsystems (3)
cover Cpu alloc slub support V2: Replace percpu allocator in slub.c
Slub also has its own per cpu allocator. Get rid of it and use cpu_alloc().
V1->V2
- Fix 2 bugs in patches (node[] array problem, inverted check)
- Change reservation of percpu area defaults.
Signature · 5 lines
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/3 Increase default reserve percpu area
SLUB now requires a portion of the per cpu reserve. There are on average about 70 real slabs on a system (aliases do not count) and each needs 12 bytes of per cpu space. Thats 840 bytes. In debug mode all slabs will be real slabs which will make us end up with 150 -> 1800.
Things work fine without this patch but then slub will reduce the percpu reserve for modules.
Percpu data must be available regardless if modules are in use or not. So get rid of the #ifdef CONFIG_MODULES.
Make the size of the percpu area dependant on the size of a machine word. That way we have larger sizes for 64 bit machines. 64 bit machines need more percpu memory since the pointer and counters may have double the size. Plus there is lots of memory available on 64 bit.
include/linux/percpu.h +1 -5
@@ -37,11 +37,7 @@extern unsigned int percpu_reserve;/* Enough to cover all DEFINE_PER_CPUs in kernel, including modules. */ #ifndef PERCPU_AREA_SIZE -#ifdef CONFIG_MODULES -#define PERCPU_RESERVE_SIZE 8192 -#else -#define PERCPU_RESERVE_SIZE 0 -#endif +#define PERCPU_RESERVE_SIZE (sizeof(unsigned long) * 2500)#define PERCPU_AREA_SIZE \ (__per_cpu_end - __per_cpu_start + percpu_reserve)
Signature · 5 lines
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 2/3 cpu alloc: Use in slub
In reply to Christoph LameterUsing cpu alloc removes the needs for the per cpu arrays in the kmem_cache struct. These could get quite big if we have to support system of up to thousands of cpus. The use of cpu_alloc means that:
1. The size of kmem_cache for SMP configuration shrinks since we will only need 1 pointer instead of NR_CPUS. The same pointer can be used by all processors. Reduces cache footprint of the allocator.
2. We can dynamically size kmem_cache according to the actual nodes in the system meaning less memory overhead for configurations that may potentially support up to 1k NUMA nodes / 4k cpus.
3. We can remove the diddle widdle with allocating and releasing of kmem_cache_cpu structures when bringing up and shutting down cpus. The cpu alloc logic will do it all for us. Removes some portions of the cpu hotplug functionality.
4. Fastpath performance increases.
include/linux/slub_def.h +1 -5
@@ -68,6 +68,7 @@* Slab cache management. */ struct kmem_cache { +struct kmem_cache_cpu *cpu_slab;/* Used for retriving partial slabs etc */ unsigned long flags;int size;/* The size of an object including meta data */
@@ -102,11 +103,6 @@int remote_node_defrag_ratio;struct kmem_cache_node *node[MAX_NUMNODES ];#endif -#ifdef CONFIG_SMP -struct kmem_cache_cpu *cpu_slab[NR_CPUS ]; -#else -struct kmem_cache_cpu cpu_slab; -#endif };/*
mm/slub.c +25 -155
316 lines not on this page · raw message
Signature · 5 lines
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [patch 2/3] cpu alloc: Use in slub
Christoph Lameter a ecrit :
Quoted 34 lines
Using cpu alloc removes the needs for the per cpu arrays in the
kmem_cachestruct. These could get quite big if we have to support system of up to thousands of cpus. The use ofcpu_allocmeans that:1. The size of
kmem_cachefor SMP configuration shrinks since we will only need 1 pointer instead ofNR_CPUS. The same pointer can be used by all processors. Reduces cache footprint of the allocator.2. We can dynamically size
kmem_cacheaccording to the actual nodes in the system meaning less memory overhead for configurations that may potentially support up to 1k NUMA nodes / 4k cpus.3. We can remove the diddle widdle with allocating and releasing of
kmem_cache_cpustructures when bringing up and shutting down cpus. The cpu alloc logic will do it all for us. Removes some portions of the cpu hotplug functionality.4. Fastpath performance increases.
Signed-off-by Christoph Lameter <[email protected]>Index:
linux-2.6/include/linux/slub_def.h
===================================================================include/linux/slub_def.h +1
-0@@ -68,6 +68,7 @@* Slab cache management. */ struct kmem_cache { +struct kmem_cache_cpu *cpu_slab;/* Used for retriving partial slabs etc */ unsigned long flags;int size;/* The size of an object including meta data */
include/linux/slub_def.h line 104
Quoted 2 lines
include/linux/slub_def.h +0
-0@@ -102,11 +103,6 @@int remote_node_defrag_ratio;struct kmem_cache_node *node[MAX_NUMNODES ];
Then maybe change MAX_NUMNODES to 0 or 1 to reflect node[] is dynamically sized ?
include/linux/slub_def.h line 106
Quoted 7 lines
include/linux/slub_def.h +0
-5#endif -#ifdef CONFIG_SMP -struct kmem_cache_cpu *cpu_slab[NR_CPUS ]; -#else -struct kmem_cache_cpu cpu_slab; -#endif };
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [patch 2/3] cpu alloc: Use in slub
Quoted 3 lines · Eric Dumazet
Then maybe change
MAX_NUMNODESto 0 or 1 to reflect node[] is dynamically sized ?
See kmem_cache_init(). It only allocates the used bytes. If you only have a single nodes then only 1 pointer will be allocated.
#ifdef CONFIG_NUMA
kmem_size = offsetof(struct kmem_cache, node) +
nr_node_ids * sizeof(struct kmem_cache_node *);
#else
That does not work for the statically allocated kmalloc array though.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 3/3 cpu alloc: Remove slub fields
In reply to Christoph LameterRemove the fields in kmem_cache_cpu that were used to cache data from kmem_cache when they were in different cachelines. The cacheline that holds the per cpu array pointer now also holds these values. We can cut down the struct kmem_cache_cpu size to almost half.
The get_freepointer() and set_freepointer() functions that used to be only intended for the slow path now are also useful for the hot path since access to the field does not require accessing an additional cacheline anymore. This results in consistent use of setting the freepointer for objects throughout SLUB.
Also we initialize all possible kmem_cache_cpu structures when a slab is created. No need to initialize them when a processor or node comes online. And all fields are set to zero. So just use __GFP_ZERO on cpu alloc.
--- include/linux/slub_def.h | 2 -- mm/slub.c | 39 +++++++++++---------------------------- 2 files changed, 11 insertions(+), 30 deletions(-)
include/linux/slub_def.h +0 -2
@@ -36,8 +36,6 @@void **freelist;/* Pointer to first free per cpu object */ struct page *page;/* The slab from which we are allocating */ int node;/* The node of the page (or -1 for debug) */ -unsigned int offset;/* Freepointer offset (in word units) */ -unsigned int objsize;/* Size of an object (from kmem_cache) */ #ifdef CONFIG_SLUB_STATS unsigned stat[NR_SLUB_STAT_ITEMS ];#endif
mm/slub.c +15 -62
170 lines not on this page · raw message
Signature · 5 lines
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>