[PATCH] record last user if malloc request is exact 4k

[PATCH] record last user if malloc request is exact 4k

[Olaf Hering]

Is there a reason why a 4096 malloc is not recorded?
untested patch below.


allow SLAB_STORE_USER also with an exact 4k request.

Signed-off-by: Olaf Hering <olh@suse.de>

 mm/slab.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.16-rc1-olh/mm/slab.c
===================================================================
--- linux-2.6.16-rc1-olh.orig/mm/slab.c
+++ linux-2.6.16-rc1-olh/mm/slab.c
@@ -1637,7 +1637,7 @@ kmem_cache_create (const char *name, siz
 	 * above the next power of two: caches with object sizes just above a
 	 * power of two have a significant amount of internal fragmentation.
 	 */
-	if ((size < 4096
+	if ((size <= 4096
 	     || fls(size - 1) == fls(size - 1 + 3 * BYTES_PER_WORD)))
 		flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
 	if (!(flags & SLAB_DESTROY_BY_RCU))

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Re: [PATCH] record last user if malloc request is exact 4k

[Pekka Enberg]

Hi,

On 1/30/06, Olaf Hering <olh@suse.de> wrote:
> Is there a reason why a 4096 malloc is not recorded?
> untested patch below.
>
> allow SLAB_STORE_USER also with an exact 4k request.

For architectures that have 4K pages, adding debugging overhead to 4K
objects is pretty much the worst case. Any particular reason you want
this?

                              Pekka

Re: [PATCH] record last user if malloc request is exact 4k

[Olaf Hering]

 On Mon, Jan 30, Pekka Enberg wrote:

> Hi,
> 
> On 1/30/06, Olaf Hering <olh@suse.de> wrote:
> > Is there a reason why a 4096 malloc is not recorded?
> > untested patch below.
> >
> > allow SLAB_STORE_USER also with an exact 4k request.
> 
> For architectures that have 4K pages, adding debugging overhead to 4K
> objects is pretty much the worst case. Any particular reason you want
> this?

I'm just curious.

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Re: [PATCH] record last user if malloc request is exact 4k

[Pekka Enberg]

Hi,

On Mon, Jan 30, Pekka Enberg wrote:
> > For architectures that have 4K pages, adding debugging overhead to 4K
> > objects is pretty much the worst case. Any particular reason you want
> > this?

On Mon, 2006-01-30 at 21:25 +0100, Olaf Hering wrote:
> I'm just curious.

Oh, okay. One or more pages are allocated for each slab depending on
object size. Each slab is then divided into equal-sized buffers which
must fit at one object. A buffer also has optional padding so that
objects respect alignment rules given to a cache. In addition, when
CONFIG_DEBUG_SLAB is enabled, the buffer contains space for red-zone on
left and right of the object and last user information.

When all debugging is enable, the total overhead is padding plus 4 *
sizeof(void *) for red-zoning and one more sizeof(void *) for the last
caller address. If you allow debugging for 4K objects, you have huge
internal fragmentation for both 4 KB and 8 KB pages (almost one full
page). The current 4095 limit isn't perfect either but increasing will
only make things worse. I think it's designed for
<linux/kmalloc_sizes.h> so that the last general object size with
debugging is 2048.

			Pekka