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

[Alexey Starikovskiy <aystarik@gmail.com>]

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.



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