Re: [patch 1/8] slub: rename slab_objects to show_slab_objects

Re: [patch 1/8] slub: rename slab_objects to show_slab_objects

[Pekka Enberg]

Christoph Lameter wrote:
> 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 <clameter@sgi.com>

Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 8/8] slub: Make the order configurable for each slab cache

[Pekka Enberg]

Hi Christoph,

Christoph Lameter wrote:
> Makes /sys/kernel/slab/<slabname>/order writable. The allocation
> order can then be changed dynamically during runtime.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
> 
> ---
>  mm/slub.c |   17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> +static ssize_t order_store(struct kmem_cache *s,
> +				const char *buf, size_t length)
> +{
> +	int order = simple_strtoul(buf, NULL, 10);
> +
> +	if (order > slub_max_order)
> +		return -EINVAL;
> +
> +	s->order = order;
> +	calculate_sizes(s);
> +	return length;

I think we need to respect slub_min_order here as well and most 
importantly, check whether cache size allows the given order; otherwise 
calculate_sizes can end up with -1 set to s->order which makes the cache 
useless (and probably makes SLUB oops).

			Pekka

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 2/8] slub: Add function to determine the amount of objects that can reside in a given slab

[Pekka Enberg]

Christoph Lameter wrote:
> 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 <clameter@sgi.com>

Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 3/8] slub: for_each_object must be passed the number of objects in a slab

[Pekka Enberg]

Christoph Lameter wrote:
> Pass the number of objects to the for_each_object macro.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>

Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 4/8] slub: Update statistics handling for variable order slabs

[Pekka Enberg]

Christoph Lameter wrote:
> 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 <clameter@sgi.com>
> 
> @@ -70,7 +71,7 @@ struct kmem_cache {
>  	struct kmem_cache_node local_node;
>  
>  	/* Allocation and freeing of slabs */
> -	int objects;		/* Number of objects in slab */
> +	int objects;		/* Number of objects in a slab of maximum size */

So why not rename this to max_objects then so we can reuse objects for 
objects0? Rest of the patch looks good to me.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 5/8] slub: Fallback to order 0 during slab page allocation

[Pekka Enberg]

Christoph Lameter wrote:
> 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 <clameter@sgi.com>
> 
> ---
>  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
> ===================================================================
> --- linux-2.6.orig/include/linux/slub_def.h	2008-02-15 13:58:28.705371769 -0800
> +++ linux-2.6/include/linux/slub_def.h	2008-02-15 13:59:48.918454617 -0800
> @@ -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 {
> @@ -72,6 +73,7 @@ struct kmem_cache {
>  
>  	/* Allocation and freeing of slabs */
>  	int objects;		/* Number of objects in a slab of maximum size */
> +	int objects0;		/* Number of object in an order 0 size slab */

As I mentioned in a previous mail, I think the should be "max_objects" 
and "objects", respectively. Other than that, looks good.

Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 6/8] slub: Drop fallback to page allocator method

[Pekka Enberg]

Christoph Lameter wrote:
> Since there is now a in slub method of falling back to an order 0 slab we no
> longer need the fallback to the page allocator.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>

> @@ -2614,7 +2585,7 @@ static struct kmem_cache *create_kmalloc
>  
>  	down_write(&slub_lock);
>  	if (!kmem_cache_open(s, gfp_flags, name, size, ARCH_KMALLOC_MINALIGN,
> -			flags | __KMALLOC_CACHE, NULL))
> +								flags, NULL))

Did you fell asleep on the tab key? The indentation looks pretty crazy 
right here ;-)-

Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 7/8] slub: Adjust order boundaries and minimum objects per slab.

[Pekka Enberg]

Hi Christoph,

Christoph Lameter wrote:
> 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 <clameter@sgi.com>
> 
> ---
>  mm/slub.c |   24 ++++--------------------
>  1 file changed, 4 insertions(+), 20 deletions(-)
> 
> Index: linux-2.6/mm/slub.c
> ===================================================================
> --- linux-2.6.orig/mm/slub.c	2008-02-15 14:16:15.383080863 -0800
> +++ linux-2.6/mm/slub.c	2008-02-15 14:16:20.947052929 -0800
> @@ -156,24 +156,8 @@ static inline void ClearSlabDebug(struct
> +#define DEFAULT_MAX_ORDER 6
> +#define DEFAULT_MIN_OBJECTS 60

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?

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 0/8] [RFC] SLUB: Variable order slab support

[Pekka Enberg]

Christoph Lameter wrote:
> 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.

Perhaps it doesn't matter as much. If the higher order allocation fails, 
we're probably badly fragmented or running out of memory, so dropping to 
order 0 sounds reasonable. The only shortcoming of that is that we might 
cause a lot of internal fragmentation within the slab for objects that 
don't fit into a page nicely.

			Pekka

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 7/8] slub: Adjust order boundaries and minimum objects per slab.

[Christoph Lameter]

On Sat, 16 Feb 2008, Pekka Enberg wrote:

> 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.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 7/8] slub: Adjust order boundaries and minimum objects per slab.

[Matt Mackall]

On Sat, 2008-02-16 at 11:00 -0800, Christoph Lameter wrote:
> On Sat, 16 Feb 2008, Pekka Enberg wrote:
> 
> > 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.

-- 
Mathematics is the supreme nostalgia of our time.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 7/8] slub: Adjust order boundaries and minimum objects per slab.

[Christoph Lameter]

On Sat, 16 Feb 2008, Matt Mackall wrote:

> Why are 4k objects even going through SLUB?

Because the page allocator is slower by factor 8.

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

We allocate one page and return it.
 
> 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.

All allocations can fall back to order 0 allocs with the patchset we are 
discussing.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>