From: Segher Boessenkool <segher@koffie.nl>
To: linuxppc-dev@lists.linuxppc.org
Subject: RFC: Performance Monitor Counters device
Date: Thu, 12 Sep 2002 22:03:02 +0200 [thread overview]
Message-ID: <3D80F2F7.3FB3AE4B@koffie.nl> (raw)
Hi people,
I'm currently implementing a Linux driver to use the PowerPC
performance monitor counters (PMC's). I thought I'd ask here
about some design/implementation issues, before I do a lot
of stupid/timewasting things ;)
The goal of this driver is threefold:
1) provide an easy interface for programs to be able to monitor
themselves -> need to change your programs code, very
fine-grained profiling.
2) provide a little more capable interface to use with something
like gmon.
3) and you can do all that on the kernel, too.
For 1), the program-to-be-monitored just needs to be able to
select a set of PMC's, and read the counters. Pretty easy.
For 2), you need the same as for 1), plus have the kernel
generate a signal on every Nth occurence of some event. The
PowerPC generates an exception for that, so this is not all
that hard either. Maybe the kernel can communicate which PMC
set off the signal; if not, it's trivial for the userland to
figure that out from the current counters.
For 3), it's just the same as above, except the niggly details
I left out (that are needed there, too): you need to select
whether the counters count event in supervisor and/or in
problem state, and/or only on marked tasks.
Now the questions ;)
1) What's the best interface for this kind of thing? A char
device? With ioctl()'s? a sysctl? something in /proc?
I'm not interested in ease of implementation (I'll have to
hack some on gprof too, for this -- so I'm not afraid of
the kernel ;) ), but in what's philosophically/technically/
procatically the best interface.
2) Do we want to be able to profile several tasks (independently
from each other) at once? This will require some bookkeeping
and task switch overhead, and is probably not necessary in
practice; also, it will degrade the quality of the results some.
3) [I'm ashamed I have to ask this...] Is there a good tutorial
to kernel locks somewhere?
4) Security: I want to generate most of the settings in userland,
for maximum ease of use and ease of implementation; but that
brings up some security issues. Only allowing root to
profile code isn't ideal, either. So:
a) Don't automagically load the module; if root loads it, let's
hope he knows what he's doing;
b) Have the pmc device be accessible only to a 'trusted' group;
c) A setuid driver program to start profiling;
d) Something much more clever?
Thanks to anyone who read this far,
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next reply other threads:[~2002-09-12 20:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-12 20:03 Segher Boessenkool [this message]
2002-09-12 9:52 ` RFC: Performance Monitor Counters device Benjamin Herrenschmidt
2002-09-12 21:45 ` Segher Boessenkool
2002-09-12 10:25 ` Benjamin Herrenschmidt
2002-09-14 11:28 ` Segher Boessenkool
2002-09-15 12:50 ` samuel
2002-09-16 12:38 ` Benjamin Herrenschmidt
2002-09-16 23:50 ` Segher Boessenkool
2002-09-13 3:32 ` Paul Mackerras
2002-09-14 11:36 ` Segher Boessenkool
2002-09-13 10:04 ` Anton Blanchard
2002-09-14 11:39 ` Segher Boessenkool
2002-09-13 22:21 ` David Engebretsen
2002-09-14 11:22 ` Segher Boessenkool
2002-09-16 15:14 ` Dave Engebretsen
2002-09-17 4:59 ` Segher Boessenkool
2002-09-14 4:41 ` Ethan Benson
2002-09-15 1:37 ` Rob Latham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D80F2F7.3FB3AE4B@koffie.nl \
--to=segher@koffie.nl \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).