linux-kernel - Re: [patch 2/2] slqb: dynamic array allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1233671240.22926.60.camel@penberg-laptop>
Date:	Tue, 03 Feb 2009 16:27:20 +0200
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	cl@...ux-foundation.org
Subject: Re: [patch 2/2] slqb: dynamic array allocations

Hi Nick,

On Tue, 2009-02-03 at 15:07 +0100, Nick Piggin wrote:
> It would be nice to keep this changeset in history if it gets merged upstream.
> I don't know for sure if there won't be a performance impact.

The 'topic/slqb/core' branch in slab.git is append-only so when you want
to merge this with Linus, we can always just ask him to pull. I don't
see much reason to fiddle with the history. After all, it's hidden under
a new config option so it's not like it's going to break git bisect or
anything.

On Tue, 2009-02-03 at 15:07 +0100, Nick Piggin wrote:
> Implement dynamic allocation for SLQB per-cpu and per-node arrays. This
> should hopefully have minimal runtime performance impact, because although
> there is an extra level of indirection to do allocations, the pointer should
> be in the cache hot area of the struct kmem_cache.
> 
> It's not quite possible to use dynamic percpu allocator for this: firstly,
> that subsystem uses the slab allocator. Secondly, it doesn't have good
> support for per-node data. If those problems were improved, we could use it.
> For now, just implement a very very simple allocator until the kmalloc
> caches are up.
> 
> On x86-64 with a NUMA MAXCPUS config, sizes look like this:
>    text    data     bss     dec     hex filename
>   29960  259565     100  289625   46b59 mm/slab.o
>   34130  497130     696  531956   81df4 mm/slub.o
>   24575 1634267  111136 1769978  1b01fa mm/slqb.o
>   24845   13959     712   39516    9a5c mm/slqb.o + this patch
> 
> SLQB is now 2 orders of magnitude smaller than it was, and an order of
> magnitude smaller than SLAB or SLUB (in total size -- text size has
> always been smaller). So it should now be very suitable for distro-type
> configs in this respect.

I think Christoph's percpu allocator is supposed to fix it up for SLUB.
We can probably switch SLQB over as well when that work hits mainline.

On Tue, 2009-02-03 at 15:07 +0100, Nick Piggin wrote:
> As a side-effect the UP version of cpu_slab (which is embedded directly
> in the kmem_cache struct) moves up to the hot cachelines, so it need no
> longer be cacheline aligned on UP. The overall result should be a
> reduction in cacheline footprint on UP kernels.
> 
> Signed-off-by: Nick Piggin <npiggin@...e.de>

Applied, thanks!

			Pekka

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/