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

Pekka Enberg
2008-12-01T17:25:08Z

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.