linux-kernel - Re: [PATCHSET x86/core/percpu] improve the first percpu chunk allocation

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:	Tue, 24 Feb 2009 23:47:23 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	rusty@...tcorp.com.au, tglx@...utronix.de, x86@...nel.org,
	linux-kernel@...r.kernel.org, hpa@...or.com, jeremy@...p.org,
	cpw@....com, nickpiggin@...oo.com.au, ink@...assic.park.msu.ru
Subject: Re: [PATCHSET x86/core/percpu] improve the first percpu chunk	allocation

Hi,

Ingo Molnar wrote:
--snip--
> So what i'm saying is that these are strong reasons for us to 
> want to make the unit size to be something like 2MB - on 64-bit 
> x86 at least.
>
> ( Using a 2MB unit size will also have another advantage: _iff_ 
>   we can still allocate a hugepage at that point we can map it 
>   straight there when extending the dynamic area. )

Thanks for the explanation.  Yeap, it would be nice to have units
aligned on 2MB boundary.  We'll need to add @align to vm area alloc
function to do it correctly.  As for using large page, it would be
nice if we can do that automatically.  Upfront 2MB unit allocation is
probably too expensive but merging 4k pages into a large page (if we
can get them) will add a lot of irregular latency too.  Hmmm...

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