Messages in this thread | | | Date | Thu, 28 Sep 2006 00:56:08 -0700 | From | Stephane Eranian <> | Subject | Re: 2.6.18 perfmon new code base + libpfm + pfmon |
| |
Andi,
On Thu, Sep 28, 2006 at 09:32:39AM +0200, Andi Kleen wrote: > Stephane Eranian <eranian@hpl.hp.com> writes: > > > > [ak] : separate patch for _TIF_WORK_CTXSW > > - I think I submitted a TIF patch for x86-64, but unlike i386 it is not yet in mainline > > If it's not in mainline yet I lost it somehow and you should resubmit. > Will do.
> > [ak] : may have to add __kprobes to some functions > > - started doing this on some functions. Need better understanding on when to use this > > Basically when you could recurse in kprobes. > My understanding is that kprobes are triggered by breakpoints, so I am think that any perfmon function that can be called along the same path, i.e., traps, needs to have the __kprobes prefix.
> > [ak] : cleaner integration with NMI watchdog > > - integration done on AMD K8. Issues on P4, P6, due to PMU design > > What are the issues?
This is ugly!
The P6 PMU actually has only one enable bit for all counters and it is in PERFEVTSEL0 which you are using for NMI. Thus counters are NOT independent. Architectural perfmon looks like it is fixing this issue. I am not sure this is actually true based on the findings of the PAPI people for instance.
The P4 PMU has independent counters, i.e., enable bits. The issue is that to stop a counter requires clearing the CCCR which also contains the overflow information (has the counter overflowed?). So you need to read the CCCR, save the value somewhere, clear the CCCR. You need some save area that you can safely access without grabbing any lock (because you are in the NMI handler). I cannot use the perfmon context because it could be accessed from other processors, and I would need to grab the context lock. I need to investigate how to do this in a different way. Maybe change the logic used to detect which counters overflowed by not using CCCR.
> > > [akpm]: documentation for syscall? Is there an API specification? > > - answered. In short, there exists a specification but it needs to be updated > > Probably you should have man pages ready for submission to the manpage maintainer. > That might also the second review pass on l-k easier if you supply > them in the description.
I don't have the man pages ready yet.
-- -Stephane - 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/
| |