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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0711010601430.27666@schroedinger.engr.sgi.com>
Date:	Thu, 1 Nov 2007 06:03:44 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	David Miller <davem@...emloft.net>
cc:	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 Thu, 1 Nov 2007, David Miller wrote:

> > This hunk helped the sparc64 looping OOPS I was getting, but cpus hang
> > in some other fashion soon afterwards.
> 
> And if I bump PER_CPU_ALLOC_SIZE up to 128K it seems to mostly work.

Good....

> You'll definitely need to make this work dynamically somehow.

Obviously. Any ideas how?

I can probably calculate the size based on the number of online nodes when 
the per cpu areas are setup. But the setup is done before we even parse 
command line arguments. That would still mean a fixed size after bootup.

In order to make it truly dynamic we would have to virtually map the area. 
vmap? But that reduces performance.

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