Messages in this thread | | | Date | Wed, 07 Jan 2009 21:13:25 +0900 | From | Tejun Heo <> | Subject | Re: regarding the x86_64 zero-based percpu patches |
| |
(cc'ing people from the original thread and LKML as it seems to require actual discussion.)
Hello, this thread started with me asking for help regarding the zero-based percpu patches and the initial message is quoted below.
Ingo Molnar wrote: > * Tejun Heo <tj@kernel.org> wrote: > >> Hello, Mike, Ingo. >> >> I was working on something which requires better dynamic per-cpu >> performance and have been working on implementing it myself but >> realized the strange gcc stack protector ABI limitation and with >> Rusty's hint and googling found out that Mike already did the heavy >> lifting. >> >> I read the "x86_64: Optimize percpu accesses" from July last year and >> it looks like it got stuck on tool chain problem which showed up as >> two problems (is one of the two resolved?). >> >> * Notifier call chain corruption >> >> * Stack overflow with default stack size >> >> >From the cpu_alloc thread from November, it seems Mike is quite >> pre-occupied, so I'm willing to give it a shot as it's blocking stuff >> I have in queue. The problem is that I'm having problem finding some >> information. >> >> 1. Mike seems to have splitted the patch but haven't posted them. >> >> 2. Ingo's x86/percpu-zerobased branch doesn't contain any revision not >> in the current upstream. Maybe the commits got lost during merges? >> >> 3. What failed and what got fixed and how to reproduce the problem. >> >> So, can you please help me a bit? I'll be happy to forward port the >> patches if they have bit-rotted. > > hm, i zapped them two days ago, because they collided with Rusty's ongoing > percpu-alloc work in his tree. Mike should be able to tell you what the > plans are for the resurrection of those patches.
IIUC, Rusty is somewhat leaning toward limiting per-cpu area and using static allocator. (right?) As I was trying to do more stuff per-cpu (not putting a lot of stuff into per-cpu area but even with small things limited per-cpu area poses scalability problems), cpu_alloc seems to fit the bill better.
Anyways, I think it's worthwhile to listen what people have on mind regarding how per-cpu stuff should proceed.
Thanks.
-- tejun
| |