Re: [PATCH 2.6.12-rc1-mm5 1/3] perfctr: ppc64 arch hooks

[Mikael Pettersson]

Andrew Morton writes:
 > David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
 > >
 > > On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote:
 > > > Mikael Pettersson <mikpe@xxxxxxxxx> wrote:
 > > > >
 > > > > Here's a 3-part patch kit which adds a ppc64 driver to perfctr,
 > > > > written by David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>.
 > > > 
 > > > 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)?

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