Re: [GIT PULL] Performance Counters for Linux

Ingo Molnar
2009-06-11T21:14:35Z

* Marcel Holtmann <marcel@holtmann.org> wrote:

> Hi Ingo,
>
> > > What the "keep it in the kernel sources" approach hopefully allows is
> > >
> > > - taking advantage of new features in a timely manner.
> > >
> > > NOT with some ABI breakage, but simply things like supporting a
> > > new CPU architecture or new counters. The thing that oprofile
> > > failed at so badly in my experience.
> > >
> > > - Make it easier for developers, and _avoiding_ the horrible
> > > situation where you have two different groups that don't talk
> > > well to each other because one is a group of user-space
> > > weenies, and the other is a group of manly kernel people, and
> > > there is no common ground.
> >
> > Yes, very much agreed.
> >
> > Btw., here are a couple of other arguments why i find it useful to
> > have the tools/perf/ in the kernel repo:
> >
> > 1) Super-fast and synchronized release cycles
> >
> > The kernel is one of the fastest moving packages in Linux - most
> > user-space packages have (much!) longer release cycles than 3
> > months.
>
> that might be true for some projects, but for others this is
> wrong. You are just making an assumption out of thin air.
>
> > A tight release schedule forces a certain amount of release
> > discipline on tooling as well - so i'm glad that the two will be
> > coupled. It's so easy for a promising tool to degrade into
> > tinkerware with odd release cycles with time - if it's part of
> > the kernel then at least the release cycles wont be odd but at
> > precise 3 months.
>
> And you can't do that within a perf.git tree on kernel.org
> because?

We actually tried the tools as separate code, and for the first
three months of the project we only got three contributions - while
the kernel code was essentially finished. (Pekka reported a similar
experience in this thread, with another tool that has close kernel
ties.)

Once we moved it into the same repo as the kernel code (three months
ago), the patches started flowing in - at an amazing rate. We now
have a dozen contributors, most of them kernel developers, and we
have over a hundred good changes to the tools - in just another 3
months.

The key difference was the location of the tools. It is very
convenient and productive to have a shared repository for a project
that frequently involves both kernel and tool changes.

So my point is: this model clearly works in practice and all the
current tools/perf/ contributors like this kind of coding
environment.

Most of your arguments seem to center around the notion that it
could all be done in a separate repo too and that such a repo could
be run as well as the Linux kernel. If you think you could do it
even better in a separate repo you are certainly free to try it.

Ingo