linux-kernel - Re: [patch 0/7] [RFC] SLUB: Improve allocpercpu to reduce per cpu access overhead

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0711020826040.26717@schroedinger.engr.sgi.com>
Date:	Fri, 2 Nov 2007 08:29:38 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	mathieu.desnoyers@...ymtl.ca, penberg@...helsinki.fi
Subject: Re: [patch 0/7] [RFC] SLUB: Improve allocpercpu to reduce per cpu
 access overhead

On Fri, 2 Nov 2007, Peter Zijlstra wrote:

> On Fri, 2007-11-02 at 07:35 -0700, Christoph Lameter wrote:
> 
> > Well I wonder if I should introduce it not as a replacement but as an 
> > alternative to allocpercpu? We can then gradually switch over. The 
> > existing API does not allow the specification of gfp_masks or alignements.
> 
> I've thought about suggesting that very thing. However, I think we need
> to have a clear view of where we're going with that so that we don't end
> up with two per cpu allocators because some users could not be converted
> over or some such.

At least in my tests so far show that it can be a full replacement but 
then I have only tested on x86_64 and Ia64. Its likely much easier to go
for the full replacement rather than in steps.

If we want dynamically sized virtually mapped per cpu areas then we may 
have issues on 32 bit platforms and with !MMU. So I would think that a 
fallback to a statically sized version may be needed. On the other hand
!MMU and 32 bit do not support a large number of processors. So we may be 
able to get away on 32 bit with a small virtual memory area.

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