Re: [perfmon] Re: [perfmon2] perfmon2 merge news

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 13 Nov 2007 10:59:24 -0800 Greg KH <gregkh@suse.de> wrote:

> On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
> > 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. 
> 
> "somber"?
> 
> Why?
> 
> We (a number of the kernel developers) want to see the perfmon code make
> it into the kernel tree, unfortunatly, in the current state it is in,
> that's not going to happen.
> 
> Andi specified a way that this can happen, just refactor your patches
> into smaller bits that can be reviewed and applied.
> 
> If you, or anyone else has any questions about this, please let us know.
> So far, I have not seen any response to his message, so I'm guessing
> that the perfmon developers either are off working on this, or don't
> care.
> 
> And if they don't care, then yes, I agree with your "somber" feeling...
> 

Well...  Philip is (I assume) a numerical-computing guy and not a
kernel-developing guy (probably a wise choice).

He speaks for quite a few people - they have serious need for this feature
but they've had to scruff around with out-of-tree patches for years to get
it, and still there are problems.

I was hoping that after the round of release-and-review which Stephane,
Andi and I did about twelve months ago that we were on track to merge the
perfmon codebase as-offered.  But now it turns out that the sentiment is
that the code simply has too many bells-and-whistles to be acceptable.

My problem with that sentiment is that it is quite likely the case that
those bells-n-whistles are actually useful and needed features.  Perfmon
has been out there for quite a few years and the code which is in there
_should_ be in response to real-world in-the-field experience.  Such
requirements never go away.


So.  If what I am saying is correct then the best course of action would be
for Stephane to help us all to understand what these features are and why
we need them.  The ideal way in which to do this is

[patch] perfmon: core
[patch] perfmon: whizzy feature #1
[patch] perfmon: whizzy feature #2
[patch] perfmon: whizzy feature #3

etc.  Where the changelog in each whizzy-feature-n explains what it does,
why it does it and why our users need it.

Whatever happens, perfmon is so big and so old and has been out-of-tree for
so long that it's going to take a pile of work from lots of people to get
any of it landed.