Hi Stephane et al,
Once concern I think many people might have, me included, is that while
this two-prong approach seems doable (though painful), it won't result
in a full-featured perfmon2 in the LKML anytime soon.
If you put on your forcaster's hat, can you make a ballpark estimate as
to when some of the more advanced features (e.g. multiplexing) would
make it into the LKML? Are we talking 18 months? Two years?
Obviously, having perfmon2 in RHEL, SLES, etc. is a lot more desirable
than having it in some fixed kernel sitting on an obscure location on
I have very little experience with Linux kernel development, so please
forgive my ignorance if this sounds daft: is there another approach that
could work where there's a core perfmon2 module in LKML, and the rest is
added in with kernel modules which plug into the core using some
pre-planned hooks? In that case, people that want to use just the core
perfmon don't have to add anything. Those that want the more advanced
features could download the module source from your git tree (or other
location), and then build them into their distro's SRPM tree to create
and install the modules they want. This way, they get to run the distro
they want, and have the ability to add whatever perfmon features they
want. One issue with that would be the need to patch perfmon/Kconfig
(if the add-in modules weren't loaded on demand) and perfmon/Makefile.
So perhaps it could be done with patches, but then the patches may have
to be distro-specific. Are there other approaches that have been taken
for this sort of thing in the past?
This could be just an interim solution until all of the perfmon2
functionality trickles into the LKML, or you could leave it in long-term.
Phil Mucci wrote:
> HI Stefane,
> In light of the recent discussions, I would request as a vendor that
> we fork perfmon2 into two branches:
> 1) That can be hacked up for the LKML folks into whatever form it needs
> 2) One that runs on a stable kernel platform (I nominate 2.6.22) and
> that only has bug fixes applied and contains the current supported
> As a vendor, I need a stable platform until this all gets resolved.
> It is without question that the Perfmon2 interface will change over
> time to make it into the kernel. SiCortex, SGI, IBM and Cray are
> wedded to this infrastructure and we need to be able to propagate
> fixes against a stable base, without worrying about feature removal
> or linux rev compatibility.
IBM Linux Technology Center, Linux Toolchain
From: Robert Richter <robert.richter@am...> - 2007-11-19 14:23:31
On 16.11.07 14:27:37, Corey Ashford wrote:
> If you put on your forcaster's hat, can you make a ballpark estimate as
> to when some of the more advanced features (e.g. multiplexing) would
> make it into the LKML? Are we talking 18 months? Two years?
There is no forecast possible for this.
> Obviously, having perfmon2 in RHEL, SLES, etc. is a lot more desirable
> than having it in some fixed kernel sitting on an obscure location on
Unless there are customers with urgent needs, it will be difficult to
get code into RHEL or SLES that will never go upstream to kernel.org.
Advanced Micro Devices, Inc.
Operating System Research Center