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... 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. > And, probably you run at 32-bit? This is part of my .config: No, 64 bit. > -------------------------------------------- > CONFIG_SLUB_DEBUG=y > # CONFIG_SLAB is not set > CONFIG_SLUB=y > # CONFIG_SLOB is not set > ------------------------------------------- > > With your patch you would be able to save 64*(2773 - 2641) + 32 * > (1792-1711)= 8448 + 2592 = 11040 bytes of memory, less than 3 pages? You don't account the cost of the kmem cache. Or fragmentation that can be caused with extra kmem caches. I guess neither is any problem with SLOB, which is used by tiny systems... > 2856 * (96-72) = 68544 bytes and 170 * (64-48) = 2720 bytes, so you will be > wasting 5 times more memory in 64 bit case. With debugging on, in which case you're wasting memory anyway. -- 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
