On Tue, Mar 23, 2010 at 07:16, Ingo Molnar <mingo@xxxxxxx> wrote: > * Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> 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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html