Add the two methods needed for defragmentation and add the display of the
methods via the proc interface.

Add documentation explaining the use of these methods and the prototypes
for slab.h. Add functions to setup the defrag methods for a slab cache.

Add empty functions for SLAB/SLOB. The API is generic so it
could be theoretically implemented for either allocator.

Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

---
 include/linux/slab.h     |   50 +++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/slub_def.h |    3 ++
 mm/slub.c                |   29 ++++++++++++++++++++++++++-
 3 files changed, 81 insertions(+), 1 deletion(-)

Index: linux-2.6/include/linux/slub_def.h
===================================================================
--- linux-2.6.orig/include/linux/slub_def.h	2008-07-31 12:19:28.000000000 -0500
+++ linux-2.6/include/linux/slub_def.h	2008-07-31 12:19:39.000000000 -0500
@@ -86,6 +86,9 @@
 	gfp_t allocflags;	/* gfp flags to use on each alloc */
 	int refcount;		/* Refcount for slab cache destroy */
 	void (*ctor)(void *);
+	kmem_defrag_get_func *get;
+	kmem_defrag_kick_func *kick;
+
 	int inuse;		/* Offset to metadata */
 	int align;		/* Alignment */
 	int defrag_ratio;	/*
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c	2008-07-31 12:19:28.000000000 -0500
+++ linux-2.6/mm/slub.c	2008-07-31 12:19:48.000000000 -0500
@@ -2736,6 +2736,19 @@
 }
 EXPORT_SYMBOL(kfree);
 
+void kmem_cache_setup_defrag(struct kmem_cache *s,
+	kmem_defrag_get_func get, kmem_defrag_kick_func kick)
+{
+	/*
+	 * Defragmentable slabs must have a ctor otherwise objects may be
+	 * in an undetermined state after they are allocated.
+	 */
+	BUG_ON(!s->ctor);
+	s->get = get;
+	s->kick = kick;
+}
+E...
[ message continues ]

Andrew,

As requested I've split the patch I sent earlier today
("utimensat() non-conformances and fixes [v4] (patch)") into
four parts.  Ideally, these should be applied for 2.6.26-rc,
for the reasons outlined in my earlier mail
"utimensat() non-conformances and fixes [v4] (test results)".

The four patches can be applied independently, but patch 3
needs patch 2 in order to work properly.

My apologies for not doing this right the first time round,
and hopefully I did get it all right this time.

Cheers,

Michael

PS Just for reference, I'll include my earlier "overview"
message here:

-------- Original Message --------
Subject: utimensat() non-conformances and fixes [v4] (overview)
Date: Tue, 03 Jun 2008 22:13:32 +0200
From: Michael Kerrisk <mtk.manpages@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
CC: lkml <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@lst.de>,  Miklos Szeredi <miklos@szeredi.hu>, Al Viro
<viro@zeniv.linux.org.uk>,  jamie@shareable.org,  Ulrich Drepper <drepper@redhat.com>,  linux-fsdevel@vger.kernel.org,
Subrata Modak <subrata@linux.vnet.ibm.com>

Andrew,

A follow-on to this mail is a patch (against 2.6.26-rc4) for -mm.  The
patch fixes several problems in the utimensat() system call.

I would like to see this patch get into mainline ASAP.  If you don't want
to push it for .26, I can understand that, since we are late in the cycle.
 Nevertheless, I will provide some arguments in favor of doing so, in a
follow-on mail.  (I'll also provide a fairly comprehensive test suite, and
test results, which may make you feel fairly confident of the patch.)

==

In an earlier mail I described four problems with the utimensat()
implementation, and attempted a clumsy fix,
http://thread.gmane.org/gmane.linux.man/129

Miklos pointed out a number of problems in my attempted fix, and pushed a
fix into .26-rc for one of the problems (number 3 in the mail), which was a
security-related issue (http...
[ message continues ]