linux-kernel - Re: [PATCHSET x86/core/percpu] implement dynamic percpu allocator

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]

Date:	Sun, 22 Feb 2009 20:27:48 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tejun Heo <tj@...nel.org>
Cc:	rusty@...tcorp.com.au, tglx@...utronix.de, x86@...nel.org,
	linux-kernel@...r.kernel.org, hpa@...or.com, jeremy@...p.org,
	cpw@....com
Subject: Re: [PATCHSET x86/core/percpu] implement dynamic percpu allocator


* Tejun Heo <tj@...nel.org> wrote:

> > So i think the best (and simplest) approach is to:
> > 
> >  - allocate the static percpu area using bootmem-alloc, but 
> >    using a 2MB alignment parameter and a 2MB aligned size. Then 
> >    we can remap it to some convenient and undisturbed virtual 
> >    memory area, using 2MB TLBs. [*]
> > 
> >  - The 'partial' bit of the 2MB page (the one that is outside 
> >    the 4K-uprounded portion of __per_cpu_end - __per_cpu_start) 
> >    can then be freed via bootmem and is available as regular 
> >    pages to the rest of the kernel.
> 
> Heh... that's exactly where the problem is.  If you remap and 
> free what's left.  The remapped area and the freed area will 
> use two separate 2MB TLBs instead of one.  It's probably worse 
> than simply using 4k mappings.

Uhm, no. We'll have one extra 2MB TLB and that's it. Both the 
low linear 2MB TLB and the high remapped alias 2MB TLB will 
cover on average of 256 4K pages. A very good deal still.

We dont want to split up the static percpu area into zillions of 
small 4K TLBs - we'll rather use +1 large-TLB.

If we used 4K ptes we'd waste up to 512 TLB entries. (largely 
simplified as the number of large TLB entries smaller than that 
of 4K TLB, but still the arguments holds in terms of TLB reach.)

So there is no "TLB problem" whatsoever that i can see ...

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