lkml.org 
[lkml]   [2005]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.12-rc1-mm5 1/3] perfctr: ppc64 arch hooks
Andrew Morton writes:
> David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote:
> > > Mikael Pettersson <mikpe@csd.uu.se> wrote:
> > > >
> > > > Here's a 3-part patch kit which adds a ppc64 driver to perfctr,
> > > > written by David Gibson <david@gibson.dropbear.id.au>.
> > >
> > > 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site