linux-kernel - RE: [PATCH 09/10] percpu: implement new 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 for Android: free password hash cracker in your pocket

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

Message-ID: <57C9024A16AD2D4C97DC78E552063EA361A02359@orsmsx505.amr.corp.intel.com>
Date:	Fri, 27 Feb 2009 11:41:19 -0800
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Rusty Russell <rusty@...tcorp.com.au>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"jeremy@...p.org" <jeremy@...p.org>, "cpw@....com" <cpw@....com>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: RE: [PATCH 09/10] percpu: implement new dynamic percpu allocator

> Ah... I see, so the 64k limit for small offset.  I think what we can

The 64k currently in use is detemined by the TLB page size that was chosen
for the percpu area.  We can move up to a larger size (but supported page
sizes increase in even powers of two, so next up from 64K is 256K, then 1M).
Just changing PERCPU_PAGE_SHIFT in asm/page.h is sufficient to use a different
page size.

> do is using the first chunk for static percpu variables.  We'll still
> be able to use the same accessor by doing something like...
>
> #define unified_percpu_accessor(ptr) ({ \
>       if (__builtin_constant_p(ptr)) \
>               return r0 - unit_size + ptr; \
>       else \
>               do ar.k3 + ptr; \
>       })
>
> So, dynamic ones will be slower than normal ones but faster than what
> we currently have (it will be faster than indirect pointer
> derferencing, right?)

Depends on how many dynamic percpu accesses are being done, and how close
together they are.  The read of ar.k3 looks to take about 30ns on my test
machine.  Faster than a memory access, but slower than a cache-hit. So
a small sequence of close together dynamic percpu accesses will go
faster with dereferencing than looking at ar.k3 for each one.

 while keeping static accesses fast.  Does it
> sound okay to you?  Also, does anyone know whether there's a working
> ia64 emulator?  There doesn't seem to be any and it seems almost
> impossible to get hold of an actual ia64 machine over here.  :-(

The HP "ski" simulator: http://www.hpl.hp.com/research/linux/ski/ might
do what you want ... but I haven't actually booted a kernel on it in
a very long time.

-Tony

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