Re: [Perfctr-devel] Re: quick overview of the perfmon2 interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph Hellwig wrote:
On Thu, Dec 22, 2005 at 03:56:32AM -0800, Stephane Eranian wrote:

reason:
	- allow support of existing kernel profiling infratructures such as
	  Oprofile or VTUNE (the VTUNE driver is open-source)


last time I checked it was available in source, but not under an open-source
license.  has this changed?  In either case intel should contribute to the
kernel profiling infrastructure instead of doing their own thing.  Supporting
people to do their own private variant is always a bad thing.

Both OProfile and PAPI are open source and could use such an performance monitoring interface.

One of the problems right now is there is a patchwork of performance monitoring support. Each instrumentation system has its own set of drivers/patches. Few have support integrated into the kernel, e.g. OProfile. However, the OProfile driver provides only a subset of the performance monitoring support, system-wide sampling. The OProfile driver doesn't allow per-thread monitoring or stopwatch style measurement, which can be very useful for some performance monitoring applications.

Having specific drivers for each performance monitoring program is not the way to go. That is one of the reasons that people have problems doing performance monitoring on Linux. Each performance monitoring program has its own driver and/or set of patches to the kernel. Many application programers are not in a position to patch the kernel and to install the custom kernel on the machine so they can use performance monitoring hardware. Not everyone has root access to the machine they use, so they can install and reboot a kernel of their choosing.

Let's take an example on Itanium. Take a user running a commercial distro
based on 2.6. This user is given early access to a Montecito machine.


That scenario is totally uninteresting for kernel development.  we want
to encourage people to use upstream kernels, and not the bastardized vendor
crap.

Vendors don't want to provide "bastardized vendor crap" either. The fewer patches in the vendor distributed kernels the better.

I think you're adding totally pointless complexity everywhere for such
scenarious because HP apparently cares for such vendor mess.  Maybe you
should concentrate on what's best for upstream kernel development.  And
the most important thing is to reduce complexity by at least one magnitude.

Specifically what are the things that are "best for upstream kernel development?" What are the things that should be eliminated "to reduce complexity by at least one magnitude?"

-Will
-
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]
  Powered by Linux