Andrew Morton writes:
> David Gibson <[email protected]> wrote:
> >
> > On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote:
> > > Mikael Pettersson <[email protected]> wrote:
> > > >
> > > > Here's a 3-part patch kit which adds a ppc64 driver to perfctr,
> > > > written by David Gibson <[email protected]>.
> > >
> > > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
