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/