lkml.org 
[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 00/15] x86_64: Optimize percpu accesses

* Christoph Lameter <cl@linux-foundation.org> 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


\
 
 \ /
  Last update: 2008-07-09 22:03    [W:0.122 / U:1.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site