Prev: [RFC PATCH v4 1/2] lmb: seperate region array from lmb_region struct
Next: [PATCH] asus-laptop: Return -ENOMEM in case of failed rfkill_alloc()
From: Kyle Moffett on 24 Mar 2010 01:50
On Tue, Mar 23, 2010 at 07:16, Ingo Molnar <mingo(a)elte.hu> wrote:
> * Benjamin Herrenschmidt <benh(a)kernel.crashing.org> wrote:
>> 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!

Ingo,

I'd like to assume that you _accidentally_ picked the *worst* possible
example file in the entire repository (with the exception of anything
in arch/x86...). You should keep in mind that basically nobody doing
ARM development cares one hoot about the scheduler as long as it
"basically works"... most such systems could get away with just
SCHED_FIFO and static priorities. When you're porting the kernel to a
platform with a 250MHz in-order CPU that's going to have a load
average of zero for 99.5% of the time and a load average of 1.0 for
the other 0.5% of the time that's pretty much the *LAST* thing you
care about.

In fact, I would guess that all the excellent work that has been done
with regards to optimized SMP and UP scheduling on much busier systems
with pathological loads has meant that the scheduler is probably one
of the most reliable pieces of code for the ARM developers. If you
want some excellent examples that go the other way, I suggest looking
at gpiolib for some great examples of code that don't matter for beans
on 99.95% of X86 boxes yet are essential for any kind of real embedded
development.

So while it's possible that you could make a reasonable point about
developer time by looking at GIT commit logs... You should refrain
from making such insulting and sweeping over-generalizations by
looking at single files, particularly ones which are largely
irrelevant or immaterial for the specific subset of developers.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [RFC PATCH v4 1/2] lmb: seperate region array from lmb_region struct
Next: [PATCH] asus-laptop: Return -ENOMEM in case of failed rfkill_alloc()