Re: 2.6.18 perfmon new code base + libpfm + pfmon

[Stephane Eranian]

Andi,

On Thu, Sep 28, 2006 at 09:32:39AM +0200, Andi Kleen wrote:
> Stephane Eranian <eranian@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/