[lkml]   [2009]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] Performance Counters for Linux
    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 because?

    > 2) Performance _matters_
    > This is an argument pretty specific to perfcounters: Performance
    > analysis tools under Linux suck pretty summarily. Yet, one of the
    > major strengths of Linux is (or at least used to be) performance. So
    > i find it very fitting that the kernel community takes performance
    > analysis tooling into their own hand.
    > 3) Strict quality control under a proven mode
    > In the kernel repo i can be sure that:
    > - No one will even think of adding autofools to tools/perf/.

    That argument is non-sense. While autoconf/automake is maybe not to your
    liking, nobody forces you to use it. Projects like git, iw etc. do
    perfectly fine without it. I don't mind having autoconf/automake around.

    > - No one will send us code with Hungarian notation and two spaces
    > tabulation.

    What kind of shitty argument it is that. I enforce kernel coding style
    in my userspace project all the time. No problem with that.

    > - No one will put getopt.h into the code

    And that is so bad because?

    > - No one will rewrite it in some weird language

    And they can do as they please. You don't have to accept the re-write.
    These are all non-sense arguments. If you maintain a userspace project
    properly then you will not see any of these problems.

    > I can point contributors to well-established kernel coding
    > principles, without having to argue no end about them.

    Come on. A lot of projects use kernel coding style nowadays. That is not
    a problem here.

    > All in one - the Linux kernel is a fire breathing monster engine
    > when it comes to producing good software. Who says it that that this
    > infrastructure and experience can only be used to produce kernel
    > space code?

    And who says that all userspace people have no idea what they are doing.
    We have a lot of successful project that follow almost the same rules as
    the kernel.

    > 4) Code reuse
    > We actually use code from the kernel: list.h primitives and
    > rbtrees.c. We privatized them for now under
    > tools/perf/util/rbtree.[ch] and tools/perf/util/list.h because
    > there's some header and type pollution in them, but it would be nice
    > to include them directly and share the facilities.

    Lets see if you are making up an argument or if you are really trying to
    work this out and solve it.

    > 5) Reality check for kernel developers
    > I think kernel hackers need a reality check too. It's easy to say
    > that user-space sucks - but now there's a way and channel that
    > frustration via direct action and make a real difference. I do hope
    > that the extra superfluous mental energies visible in this thread
    > can be used for good purposes too ;-)
    > 6) It's a lot of fun
    > I never thought i'd say that - but hacking properly structured
    > user-space code in the kernel repo is serious fun. It's even
    > relaxing at times: i can be reasonably sure that i wont crash the
    > kernel.
    > All in one, we did this because we found that it produces better
    > code in practice and does it faster - and i dont think we should
    > rigidly limit the kernel repo to kernel-space projects alone.

    Linus has a bad expierience with oprofile and wants to try something new
    and I can follow that argument to a certain degree. I don't agree with
    it, but that is fine.

    So you are saying that only good code comes from including it into
    linux-2.6.git and otherwise you will never get there. Have you actually
    tried to maintain this in a separate repository on



     \ /
      Last update: 2009-06-11 22:51    [W:0.026 / U:4.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site