Hello all,
I wanted to update you on the progress towards mainline integration.
Earlier this week, I submitted most of the perfmon kernel patch
to the Linux Kernel Mailing List (LKML) for a final code review.
The patch included support for i386, x86-64, mips, powerpc. The
Itanium patch was not submitted because it is fairly large
(due to the removal of the older perfmon) and does not
fit the 100kB per message limitation. Anyway, the discussion
does mostly revolve around x86 as you might expect.
I got some feedback from Andi Kleen and Mr. Christoph
Hellwig. As usual, Andi had some good remarks and
questions. As expected, Hellwig was more negative
claiming the 'interface was a mess'.
Both complained about the overall complexity of the interface to
which I replied that it is complex because of the hardware
complexity and also because of the diversity of usage models.
Most features which would seem advanced to novice users are, in fact,
used as far as I can tell, e.g., kernel level sampling buffer, custom
sampling formats, event set multiplexing. You can probably confirm
this yourselves.
To help, I have decided to remove a couple of features which were not
really used:
- explict next set (PFM_SETFL_EXPL_NEXT): the ability to designate
a specific event set as the next set to go to.
- PMD remapping (view): the ability to remap the software-maintained
counters via mmap() to user level. This features only works on
architecture which allow reading of the counters at the user level.
Both features could be added back later. But for now, I prefer to drop
them as a sign of goodwill and also beause we have not really validated them.
As a consequence the API has changed again. I expect other changes to follow.
Andi suggested that for security reasons, instead of using the
/sys/kernel/perfmon
interface to control which users can create per-thread/system-wide contexts, we
use Linux capabilities. That looks like a good idea because we reuse an existing
infrastructure. The kernel changes were trivial. I added a couple of
capabilities
and the kernel checks against them on context creation. Now, the difficulty
is to understand how one gives the capability to users via PAM. I looked for
most of the day today and I could not find anything useful. Andi and I agree
that the capabilities need to be granted at login. I have not been able to find
a PAM module which would make the kernel syscalls to add/remove capability to
a process. Maybe somebody on this list knows more than me on this. If so
I would certainly appreciate any help.
Andi also suggested that for a transition period we allow Oprofile and perfmon
to co-exist.
That means not migrate Oprofile directly on top of perfmon as this is is done
on Itanium
and as I have shown with my Oprofile x86 patch. Co-exist meant that they are
both compiled
in the kernel and that users can alternatively use one or the other. There
would be mutual
exclusion between the two. If Oprofile runs then no perfmon context can be
created and
vice-versa. I think this is a good idea and I will look into this next week.
The key difficulty is how to deal with the NMI watchdog and register
reservation.
There were also some questions about Intel architectural perfmon support. As a
consequence,
I have restructured the perfmon_gen_ia32.c (new name perfmon_intel_arch.c) PMU
description module
a bit. I have do similarly for the perfmon_core.c. I tink both would need more
work.
Stay tuned...
--
-Stephane
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
