Thanks for the update Stefane. Of course, we are always sad to see
PMD remapping disappear in the HPC world. We have long gotten used to
the most efficient access possible to the counters through PerfCtr on
architectures that support reading the PMD's from user level.
However, it is agreed that anything that gets this into mainline is a
good thing.
I'm glad you received some constructive remarks...and of course, we
would expect nothing so from Mr. Hellwig. The guy has the
communication skills of a moldy turnip.
A request...as many of us are tracking perfmon2, is it possible to
maintain two branches of this patch? One being a 'stable' release as
it stands and one being the frankenstein created by LKML? I don't
know how much work that represents for you...
Phil
On Jun 1, 2007, at 1:38 PM, Stephane Eranian wrote:
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/
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
