linux-kernel - Re: [RFC] slub: Per object NUMA support

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: <alpine.DEB.2.00.1105120944480.24560@router.home>
Date:	Thu, 12 May 2011 09:46:26 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	David Rientjes <rientjes@...gle.com>
cc:	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC] slub: Per object NUMA support

On Wed, 11 May 2011, David Rientjes wrote:

> > Anyways the implementation is rather simple.
> >
>
> The implementation may be simple, but it seems like this would absolutely
> kill performance for MPOL_INTERLEAVE if slub is required for every
> kmalloc() or kmem_cache_alloc() to take the alternate slab node's
> list_lock to scan the partial list or, worse yet, allocate a new slab on
> that node when there are objects available on the freelist.

Right. SLAB does something similar though. We could optimize it more by
taking locks like done there and aovid the switching of the per cpu slabs.

> That, to me, would always nullify the performance benefit of using the
> mempolicy in the first place and end up making MPOL_INTERLEAVE worse than
> no mempolicy.  Do you have any benchmarks that suggest this has no
> negative impact?  I'd be very surprised.

The default is no memory policy. You would only use MPOL_INTERLEAVE on
large NUMA system that incur sufficient cross node latency to justify the
interleave.
--
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/