* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
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
--
