Re: [RFC 00/15] x86_64: Optimize percpu accesses

[Ingo Molnar]

* Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx> wrote:

> Ingo Molnar wrote:
> 
> > that makes sense. Does everyone agree on #1-#2-#3 and then gradual 
> > elimination of most pda members (without going through an 
> > intermediate renaming of pda members) being the way to go?
> 
> I think we all agree on 1-2-3.
> 
> The rest is TBD. Hope Jeremy can add his wisdom there to get the pda.X 
> replaced by the proper percpu names for 32 bit.
> 
> With Jeremy's approach we would be doing two steps at once (getting 
> rid of pda ops plus unifying the variable names between 32 and 64 
> bit). Maybe more difficult to verify correctness. The removal of the 
> pda ops is a pretty straighforward conversion.

Yes, but there's nothing magic about pda variables versus percpu 
variables. We should be able to do the pda -> unified step just as much 
as we can do a percpu -> unified step. We can think of pda as a funky, 
pre-percpu-era relic.

The only thing that percpu really offers over pda is its familarity. 
read_pda() has the per-cpu-ness embedded in it, which is nasty with 
regard to tracking preemption properties, etc.

So converting to percpu would bring us CONFIG_PREEMPT_DEBUG=y checking 
to those ex-pda variables. Today if a read_pda() (or anything but 
pcurrent) is done in a non-preempt region that's likely a bug - but 
nothing warns about it.

So in that light 4-15 might make some sense in standardizing all these 
accesses and making sure it all fits into an existing, familar API 
world, with no register level assumptions and assembly (and ABI) ties, 
which is instrumented as well, with explicit smp_processor_id() 
dependencies, etc.

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