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]

Message-ID: <20090224151920.GB12438@elte.hu>
Date:	Tue, 24 Feb 2009 16:19:20 +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, nickpiggin@...oo.com.au, ink@...assic.park.msu.ru
Subject: Re: [PATCHSET x86/core/percpu] improve the first percpu chunk
	allocation


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

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

Yeah, largepage support - if we ever get there (the chances of 
finding a proper 2MB aligned 2MB sized chunk of physical memory 
are not very good except the first few minutes of uptime), 
should indeed be automatic to all get_vm_area() users - 
vmalloc(), ioremap() and now percpu.c.

I think a far more realistic angle to utilize more of the 2MB 
TLB will be to gradually increase PERCPU_ENOUGH_ROOM, as we 
observe more and more percpu_alloc() sites in the kernel. Right 
now it's pretty rare so going beyond the 8K we do for modules 
would probably be a waste of RAM.

	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/