Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.c

[Ingo Molnar <mingo@elte.hu>]

* 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