Re: [patch][rfc] acpi: do not use kmem caches

["Pekka Enberg" <penberg@cs.helsinki.fi>]

On Mon, Dec 01, 2008 at 08:04:21PM +0300, Alexey Starikovskiy wrote:
>> Nick Piggin wrote:
>> >Hmm.
>> >Acpi-Operand        2641   2773     64   59    1 : tunables  120   60    8
>> >: slabdata     47     47     0
>> >Acpi-ParseExt          0      0     64   59    1 : tunables  120   60    8
>> >: slabdata      0      0     0
>> >Acpi-Parse             0      0     40   92    1 : tunables  120   60    8
>> >: slabdata      0      0     0
>> >Acpi-State             0      0     80   48    1 : tunables  120   60    8
>> >: slabdata      0      0     0
>> >Acpi-Namespace      1711   1792     32  112    1 : tunables  120   60    8
>> >: slabdata     16     16     0
>> >
>> >
>> >Looks different for my thinkpad.
>> >
>> Probably this is SLUB vs. SLAB thing Pecca was talking about...

On Mon, Dec 1, 2008 at 7:12 PM, Nick Piggin <npiggin@suse.de> wrote:
> Sizes should not be bigger with SLUB. Although if you have SLUB debugging
> turned on then maybe the size gets padded with redzones, but in that
> configuration you don't expect memory saving anyway because padding bloats
> things up.

Please keep in mind that SLUB slab merging kicks in and at least on
32-bit merges some of the caches with dentry caches and so forth. So
with SLUB, separate caches are probably OK. Unfortunately I don't have
any machines running with SLAB currently so I don't have any numbers.
But again, for SLAB, if there's not enough activity going on, you end
up with partially filled slabs which wastes memory.

Though I suspect using kmem caches to combat the internal
fragmentation caused by kmalloc() rounding is not worth it in this
case.

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