Hi folks,
Well, I can say the mood here at supercomputing'07 is pretty somber
in regards to the latest exchange of messages regarding the perfmon
patches. Our community has been the largest user of both the PerfCtr
and the Perfmon patches, the former being regularly installed by
vendors and integrators on clusters at install time, and the latter
now being adopted into vendor kernels by IBM, Cray, AMD, SiCortex and
others. Of course, adoption by a vendor, does not a good kernel patch
make. However, it should be viewed as a strong data point on demand
for such functionality. We are a community focused on performance and
we have long had a need for these tools.
A solution that does not provide 64 bit virtualized per-thread counts
is not a solution at all. That would need to be ripped out by all of
us using this functionality so we could get something that actually
does what the community needs, not what the you folks think we need.
Device level access and/or root access to the counters is not
unacceptable for machines in production. If that was fine, oprofile
would have satisfied everyone and we wouldn't be sucking up your
bandwidth. Please understand that people outside of the your
community are desperate for adoption of any form of 'per-thread' PMU
functionality into the kernel. For those of you who are (still) not
convinced of this, I can arrange your inbox to be spammed by 1000's
of HPC geeks, managers, vendors, etc. My point is, let's start
somewhere that the community finds useful. Otherwise we run the risk
of developing an interface that everyone isn't comfortable with and
no-one uses. Hardly a productive exercise.
So please, do consider a set of core functionality that provides for
(at least) the following:
- per-CPU and per-thread 64 bit virtualized counts
- third person operation (attach/ptrace)
- dispatch of signal upon interrupt on overflow if requested
- 'buffered' interrupts into a buffer that can be mmap'd into user space
- support for a variety of the major processor platforms
Regards,
On Nov 13, 2007, at 9:55 AM, Stephane Eranian wrote:
Hello,
On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
Robert Richter wrote:
On 10.11.07 21:32:39, Andi Kleen wrote:
It would be really good to extract a core perfmon and start with
that and then add stuff as it makes sense.
e.g. core perfmon could be something simple like just support
to context switch state and initialize counters in a basic way
and perhaps get counter numbers for RDPMC in ring3 on x86[1]
Perhaps a core could provide also as much functionality so that
Perfmon can be used with an *unpatched* kernel using loadable
modules?
One drawback with today's Perfmon is that it can not be used with a
vanilla kernel. But maybe such a core is by far too complex for a
first merge.
-Robert
Hi Robert,
In the past I suggested that it might be useful to have a version
of perfmon2
that only set up the perfmon on a global basis. That would allow
the patches for
context switches to be added as a separate step, splitting up the
patch into
smaller set of patches.
Perfmon2 uses a set of system calls to control the performance
monitoring
hardware. This would make it difficult to use an unpatch kernel
unless perfmon
changed the mechanism used to control the performance monitoring
hardware.
Yes, that would be a possibility but as you pointed out there are
some problems:
- perfmon2 uses system calls. So unless you can dynamically patch the
syscall table we would have to go back to the ioctl() and driver
model.
I was under the impression that people did not quite like
multiplexing
syscalls such as ioctl(). I also do prefer the multi syscall
approach.
- perfmon2 needs to install a PMU interrupt handler. On X86, this
is not just
an external device interrupts. There needs to be some APIC and
interrupt
gate setup. There maybe other constraints on other architectures
as well.
Not sure if all functions/structures necessary for this are
available to
modules.
- we could not support per-thread mode with the kernel module
approach due to
link to the context switch code. I do believe per-thread is a
key value-add
for performance monitoring.
--
-Stephane
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
