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

Alexey Starikovskiy
2008-12-01T17:04:24Z

Nick Piggin wrote:
> On Mon, Dec 01, 2008 at 05:48:05PM +0300, Alexey Starikovskiy wrote:
>
>> Christoph Lameter wrote:
>>
>>> On Mon, 1 Dec 2008, Pekka Enberg wrote:
>>>
>>>
>>>
>>>> Why do you think Nick's patch is going to _increase_ memory consumption?
>>>> SLUB _already_ merges the ACPI caches with kmalloc caches so you won't
>>>> see any difference there. For SLAB, it's a gain because there's not
>>>> enough activity going on which results in lots of unused space in the
>>>> slabs (which is, btw, the reason SLUB does slab merging in the first
>>>> place).
>>>>
>>>>
>>> The patch is going to increase memory consumption because the use of
>>> the kmalloc array means that the allocated object sizes are rounded up to
>>> the next power of two.
>>>
>>> I would recommend to keep the caches. Subsystem specific caches help to
>>> simplify debugging and track the memory allocated for various purposes in
>>> addition to saving the rounding up to power of two overhead.
>>> And with SLUB the creation of such caches usually does not require
>>> additional memory.
>>>
>>> Maybe it would be best to avoid kmalloc as much as possible.
>>>
>>>
>>>
>> Christoph,
>> Thanks for support, these were my thoughts, when I changed ACPICA to use
>> kmem_cache instead of
>> it's own on top of kmalloc 4 years ago...
>> Here are two acpi caches on my thinkpad z61m, IMHO any laptop will show
>> similar numbers:
>>
>> aystarik@thinkpad:~$ cat /proc/slabinfo | grep Acpi
>> Acpi-ParseExt 2856 2856 72 56 1 : tunables 0 0
>> 0 : slabdata 51 51 0
>> Acpi-Parse 170 170 48 85 1 : tunables 0 0
>> 0 : slabdata 2 2 0
>>
>> Size of first will become 96 and size of second will be 64 if kmalloc is
>> used, and we don't count ACPICA internal overhead.
>> Number of used blocks is not smallest in the list of slabs, actually it
>> is among the highest.
>>
>
> 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...
And, probably you run at 32-bit? This is part of my .config:
--------------------------------------------
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?

2856 * (96-72) = 68544 bytes and 170 * (64-48) = 2720 bytes, so you will be wasting 5 times more memory in 64 bit case.