[lkml]   [2005]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2.6.12-rc1-mm5 1/3] perfctr: ppc64 arch hooks
Andrew Morton writes:
> David Gibson <> wrote:
> >
> > On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote:
> > > Mikael Pettersson <> wrote:
> > > >
> > > > Here's a 3-part patch kit which adds a ppc64 driver to perfctr,
> > > > written by David Gibson <>.
> > >
> > > Well that seems like progress. Where do we feel that we stand wrt
> > > preparedness for merging all this up?
> >
> > I'm still uneasy about it. There were sufficient changes made getting
> > this one ready to go that I'm not confident there aren't more
> > important things to be found.
> That's a bit open-ended. How do we determine whether more things will be
> needed? How do we know when we're done?

I have two planned changes that will be done RSN:
- On x86/x86-64, user-space uses the mmap()ed state's TSC start
value as a way to detect if a user-space sampling operation
(which needs to be "virtually atomic") was preempted by the kernel.
On ppc{32,64} we've used the TB for the same thing up to now,
but that doesn't quite work because the TB is about a magnitude
or two too slow. So the plan is to change ppc to store a
software generation counter in the mmap()ed state, and change
the ppc user-space to check that one instead.
- Move <asm-$arch/perfctr.h> common stuff to <asm-generic/perfctr.h>.

In addition, there is one unresolved issue:
- A counter's value is represented by a 64-bit software sum,
a 32-bit start value containing the HW counter's value at the
start of the current time slice, and the current HW counter's value
(now). The actual value is computed as sum + (now - start).
This is reflected in the mmap()ed state, which contains a variable-
length { u32 map; u32 start; u64 sum; } pmc[] array.
This layout is very cache-efficient on current 32 and 64-bit CPUs,
but there is a _possible_ concern that it won't do on 10+ GHz CPUs.
So the question is, should we change it to use 64-bit start values
already now (and take more cache misses), or should that wait a few
years until it becomes a necessity (causing ABI change issues)?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.058 / U:1.404 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site