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