linux-kernel - Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f73f7ab81003232247t2bf36cfdubbb8dd65db8f5691@mail.gmail.com>
Date:	Wed, 24 Mar 2010 01:47:07 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	yinghai@...nel.org, tglx@...utronix.de, hpa@...or.com,
	jbarnes@...tuousgeek.org, ebiederm@...ssion.com,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c 
	to fw_memmap.c

On Tue, Mar 23, 2010 at 07:16, Ingo Molnar <mingo@...e.hu> wrote:
> * Benjamin Herrenschmidt <benh@...nel.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/