lkml.org 
[lkml]   [2010]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.c

    * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

    > On Mon, 2010-03-22 at 21:57 +0100, Ingo Molnar wrote:
    > >
    > > > You use that arguemnt ONE MORE FUCKING TIME and you'll end up in my killfile
    > > > with a auto-NACK reply of anything that looks like a patch from you.
    > >
    > > Does this mean you disagree with that? (I think it's pretty factual, last i
    > > checked the usage stats of devel kernels was somewhere around 99.7%.)
    >
    > I disagree with that being a relevant argument in the technical discussion
    > on the relative merits of two implementations of a given facility. I also
    > disagree with your numbers, if you talk about deployement, I would be very
    > very surprised if ARM wasn't close to on-par with x86.

    As an upstream maintainer i mainly care about upstream kernel contributions.
    These contributions have three main forms:

    - patches i get against latest upstream

    - on-lkml review/analysis that is done on those patches

    - test/bug/regression reports i get against latest upstream (either directly
    on lkml or via kerneloops.org or bugzilla.kernel.org)

    So i weigh the architectures based on that input.

    Since you mentioned ARM - here's the Git contribution stats. In the last 5
    years since we have kernel Git history, there's been 1080 commits to
    kernel/sched.c. Amongst those 1080 commits i could find only a _single commit_
    (a minor fix) being related to or contributed by anyone doing ARM development!

    To be on the safe side lets assume that i missed many commits, lets up that
    count to ten times of that count: 10 commits. I.e. the 'weight of ARM', when
    it comes to kernel/sched.c, is still less than 1%.

    'millions of ARM units' alone means little to me, if it does not translate
    into actual upstream kernel contributions. Many of those 'millions of units'
    are walled off from kernel contributions: the users dont even know they are
    running Linux. They are not linked to kerneloops.org and dont produce bugzilla
    bugreports. They do finance Linux developers by proxy - but as far as the
    upstream kernel is concerned they only exist to the extent they finance kernel
    developers to care about it.

    Lets look at a counter example: Sparc64. There's literally just a handful of
    Sparc64 'units' that run Linux, still the weight of the arch is much higher -
    due to the well-known highly productive kernel contributor who is using that
    architecture. I have seen about 10 times more scheduler contributions [~15
    commits] from that single unit Sparc64 angle than from the millions of ARM
    units! (and davem isnt even doing scheduler development per se - he's mostly
    doing drive-by fixes and improvements with no particular focus on the
    scheduler.)

    Or lets look at an architecture that during its development had a physical
    unit count of _zero_: SGI UV. It was only running in simulators for a year but
    it sure resulted in dozens and dozens of useful patches that extended Linux's
    scalability reach. So did SGI UV matter, despite having had a zero unit count?
    Heck it did ...

    I singled out kernel/sched.c but there's a very similar picture and
    contribution weights when it comes to other areas i co-maintain: lockdep,
    perf, tracing, etc.

    So if you want your architecture to matter to me the rule is very simple:
    contribute, contribute, contribute, and stop whining. If you dont contribute,
    frankly you dont really exist to me. On the other hand if you are actively
    contributing while your architecture only exists on paper, it already starts
    mattering to me.

    I'm really that simple.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2010-03-23 12:19    [W:4.257 / U:0.512 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site