From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by ey-out-1920.google.com with SMTP id 21so1338592eyc.44 for ; Mon, 01 Dec 2008 09:04:24 -0800 (PST) Message-ID: <49341915.5000900@gmail.com> Date: Mon, 01 Dec 2008 20:04:21 +0300 From: Alexey Starikovskiy MIME-Version: 1.0 Subject: Re: [patch][rfc] acpi: do not use kmem caches References: <20081201083128.GB2529@wotan.suse.de> <84144f020812010318v205579ean57edecf7992ec7ef@mail.gmail.com> <20081201120002.GB10790@wotan.suse.de> <4933E2C3.4020400@gmail.com> <1228138641.14439.18.camel@penberg-laptop> <4933F925.3020907@gmail.com> <20081201162018.GF10790@wotan.suse.de> In-Reply-To: <20081201162018.GF10790@wotan.suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Christoph Lameter , Pekka Enberg , Linux Memory Management List , linux-acpi@vger.kernel.org, lenb@kernel.org List-ID: 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: email@kvack.org