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@xxxxxxx> 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 from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
