slub: rename slab_objects to show_slab_objects

The sysfs callback is better named show_slab_objects since it is always called from the xxx_show callbacks. We need the name for other purposes later.

Signed-off-by Christoph Lameter <[email protected]>

Makes /sys/kernel/slab/<slabname>/order writable. The allocation order can then be changed dynamically during runtime.

Signed-off-by Christoph Lameter <[email protected]>

---
 mm/slub.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

(quoted diff) +1 -0

+static ssize_t order_store(struct kmem_cache *s,

Add a new function that determines the maximum number of objects that a given slab can accomodate. At this stage the function always returns the maximum number of objects since fallback is not available yet.

Signed-off-by Christoph Lameter <[email protected]>

Pass the number of objects to the for_each_object macro.

Signed-off-by Christoph Lameter <[email protected]>

Change the statistics to consider that slabs of the same slabcache can have different number of objects in them since they may be of different order.

Provide a new sysfs field

total_objects

which shows the total objects that the allocated slabs of a slabcache could hold.

Update the description of the objects field in the kmem_cache structure. Its role is now to be the limit of the maximum number of objects per slab if a slab is allocated with the largest possible order.

Signed-off-by Christoph Lameter <[email protected]>

If any higher order allocation fails then fall back to an order 0 allocation if the object is smaller than PAGE_SIZE.

Signed-off-by Christoph Lameter <[email protected]>

---
 include/linux/slub_def.h |    2 +
 mm/slub.c                |   54 ++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 46 insertions(+), 10 deletions(-)

Index: linux-2.6/include/linux/slub_def.h
===================================================================

include/linux/slub_def.h +1 -0

@@ -29,6 +29,7 @@ enum stat_item {
 	DEACTIVATE_TO_HEAD,	/* Cpu slab was moved to the head of partials */
 	DEACTIVATE_TO_TAIL,	/* Cpu slab was moved to the tail of partials */
 	DEACTIVATE_REMOTE_FREES,/* Slab contained remotely freed objects */
+	ORDER_FALLBACK,	/* Allocation that fell back to order 0 */
 	NR_SLUB_STAT_ITEMS };
 
 struct kmem_cache_cpu {

Since there is now no worry anymore about higher order allocs (hopefully) increase the minimum of objects per slab to 60 so that slub can reach a similar fastpath/slowpath ratio as slab. Set the max order to default to 6 (256k).

Signed-off-by Christoph Lameter <[email protected]>

---
 mm/slub.c |   24 ++++--------------------
 1 file changed, 4 insertions(+), 20 deletions(-)

Index: linux-2.6/mm/slub.c
===================================================================

These look quite excessive from memory usage point of view. I saw you dropping DEFAULT_MAX_ORDER to 4 but it seems a lot for embedded guys, at least?

Quoted 2 lines · Pekka Enberg

These look quite excessive from memory usage point of view. I saw you dropping DEFAULT_MAX_ORDER to 4 but it seems a lot for embedded guys, at least?

What would be a good max order then? 4 means we can allocate a 64k segment for 16 4k objects.

Why are 4k objects even going through SLUB?

What happens if we have 8k free and try to allocate one 4k object through SLUB?

Using an order greater than 0 is generally frowned upon. Kernels can and do get into situations where they can't find two contiguous pages, which is why we've gone to so much trouble on x86 to fit into a single page of stack.

It would be nice if the page allocator would support something like: I want a page sized Y but I am going to take anything smaller too. Then we could get where Pekka wanted to go.