netdev - RE: [PATCH] percpu: add optimized generic percpu accessors

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:	Wed, 28 Jan 2009 09:15:08 -0800
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	Rick Jones <rick.jones2@...com>,
	David Miller <davem@...emloft.net>,
	"tj@...nel.org" <tj@...nel.org>,
	"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"brgerst@...il.com" <brgerst@...il.com>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"travis@....com" <travis@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"steiner@....com" <steiner@....com>,
	"hugh@...itas.com" <hugh@...itas.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"mathieu.desnoyers@...ymtl.ca" <mathieu.desnoyers@...ymtl.ca>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>
Subject: RE: [PATCH] percpu: add optimized generic percpu accessors

> > Managing a larger space could be done ... but at the expense of making
> > the Alt-DTLB miss handler do a memory lookup to find the physical address
> > of the per-cpu page needed (assuming that we allocate a bunch of random
> > physical pages for use as per-cpu space rather than a single contiguous
> > block of physical memory).
>
> We cannot resize the area by using a single larger TLB entry?

Yes we could ... the catch is that the supported TLB page sizes go
up by multiples of 4.  So if 64K is not enough the next stop is
at 256K, then 1M, then 4M, and so on.

That's why I asked when we know what total amount of per-cpu memory
is needed.  CONFIG time or boot time is good, because allocating higher
order pages is easy at boot time.  Arbitrary run time is bad because
we might have difficulty allocating a high order page for every cpu.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html