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

* Benjamin Herrenschmidt <> 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 or

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 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

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.



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