Re: [PATCH] kmalloc_percpu

[William Lee Irwin III <wli@holomorphy.com>]

William Lee Irwin III writes:
>> This is somewhat painful to do (though possible) on i386. The cost of
>> task migration would increase at the very least.

On Wed, May 07, 2003 at 02:03:46PM +1000, Paul Mackerras wrote:
> Explain?  We're not talking about having the same address mapped
> differently on different CPUs, we're just talking about something
> which is the equivalent of a sparsely-instantiated vmalloc.

Same address mapped differently on different cpus is what I thought
you meant. It does make sense, and besides, it only really matters
when the thing is being switched in, so I think it's not such a big
deal. e.g. mark per-thread mm context with the cpu it was prepped for,
if they don't match at load-time then reset the kernel pmd's pgd entry
in the per-thread pgd at the top level. x86 blows away the TLB at the
drop of a hat anyway, and it wouldn't even introduce an extra whole-TLB
flush. That said, I'm not terribly interested in hacking all that up
even though the proper hooks to make it pure arch code appear to exist.

The vmallocspace bit is easier, though the virtualspace reservation
could get uncomfortably large depending on how much is crammed in there.
That can go node-local also. I guess it has some runtime arithmetic
overhead vs. the per-cpu TLB entries in exchange for less complex code.

-- wli