Re: regarding the x86_64 zero-based percpu patches

[Tejun Heo]

(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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/