From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Starikovskiy Subject: Re: [patch][rfc] acpi: do not use kmem caches Date: Mon, 01 Dec 2008 20:04:21 +0300 Message-ID: <49341915.5000900@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from ey-out-2122.google.com ([74.125.78.27]:16689 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790AbYLARE0 (ORCPT ); Mon, 1 Dec 2008 12:04:26 -0500 Received: by ey-out-2122.google.com with SMTP id 6so1085720eyi.37 for ; Mon, 01 Dec 2008 09:04:24 -0800 (PST) In-Reply-To: <20081201162018.GF10790@wotan.suse.de> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Nick Piggin Cc: Christoph Lameter , Pekka Enberg , Linux Memory Management List , linux-acpi@vger.kernel.org, lenb@kernel.org 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.