[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AB39D3A.3000204@openwrt.org>
Date: Fri, 18 Sep 2009 16:46:18 +0200
From: Felix Fietkau <nbd@...nwrt.org>
To: Ingo Molnar <mingo@...e.hu>
CC: Michael Buesch <mb@...sch.de>, Con Kolivas <kernel@...ivas.org>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Mike Galbraith <efault@....de>
Subject: Re: BFS vs. mainline scheduler benchmarks and measurements
Ingo Molnar wrote:
> * Michael Buesch <mb@...sch.de> wrote:
>
>> On Tuesday 08 September 2009 09:48:25 Ingo Molnar wrote:
>> > Mind poking on this one to figure out whether it's all repeatable
>> > and why that slowdown happens?
>>
>> I repeated the test several times, because I couldn't really believe
>> that there's such a big difference for me, but the results were the
>> same. I don't really know what's going on nor how to find out what's
>> going on.
>
> Well that's a really memory constrained MIPS device with like 16 MB of
> RAM or so? So having effects from small things like changing details in
> a kernel image is entirely plausible.
Normally changing small details doesn't have much of an effect. While 16
MB is indeed not that much, we do usually have around 8 MB free with a
full user space running. Changes to other subsystems normally produce
consistent and repeatable differences that seem entirely unrelated to
memory use, so any measurable difference related to scheduler changes is
unlikely to be related to the low amount of RAM.
By the way, we do frequently also test the same software with devices
that have more RAM, e.g. 32 or 64 MB and it usually behaves in a very
similar way.
- Felix
--
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/
Powered by blists - more mailing lists