BFS vs. mainline scheduler benchmarks and measurements
in [Kernel]
|
Prev: [PATCH 1/1] AGP: amd64, fix pci reference leaks
Next: [PATCH 2/3] viafb: remove unused structure member
From: Martin Steigerwald on 12 Sep 2009 07:30 Am Freitag 11 September 2009 schrieb Mat: > Martin Steigerwald <Martin <at> lichtvoll.de> writes: > > Am Donnerstag 10 September 2009 schrieb Ingo Molnar: > > [snip] > > > > what is /debug/sched_features - is NO_NEW_FAIR_SLEEPERS set? If not > > > set yet then try it: > > > > > > echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features > > > > > > that too might make things more fluid. > > Hi Martin, Hi Mat, > it made an tremendous difference which still has to be tested out :) [...] > Concerning that "NO_NEW_FAIR_SLEEPERS" switch - isn't it as easy as to > > do the following ? (I'm not sure if there's supposed to be another > debug) > > echo NO_NEW_FAIR_SLEEPERS > /sys/kernel/debug/sched_features > > which after the change says: > > cat /sys/kernel/debug/sched_features > NO_NEW_FAIR_SLEEPERS NO_NORMALIZED_SLEEPER ADAPTIVE_GRAN WAKEUP_PREEMPT > START_DEBIT AFFINE_WAKEUPS CACHE_HOT_BUDDY SYNC_WAKEUPS NO_HRTICK > NO_DOUBLE_TICK ASYM_GRAN LB_BIAS LB_WAKEUP_UPDATE ASYM_EFF_LOAD > NO_WAKEUP_OVERLAP LAST_BUDDY OWNER_SPIN > > I hope that's the correct switch ^^ Thanks. Appears to work here nicely ;-). I thought this might be a debug fs that I need to mount separately, but its already there here. I will see how it works out. I wondered whethere it might be a good idea to have a echo default > /sys/kernel/kernel-tuning-knob that will reset it to the compiled in factory defaults. Would be a nice way to go back to safe settings again once you got carried away to far with trying those tuning knobs. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
From: Frans Pop on 16 Sep 2009 14:30 Benjamin Herrenschmidt wrote: > I'll have a look after the merge window madness. Multiple windows is > also still an option I suppose even if i don't like it that much: we > could support double-click on an app or "global" in the left list, > making that pop a new window with the same content as the right pane for > that app (or global) that updates at the same time as the rest. I have another request. If I select a specific application to watch (say a mail client) but it is idle for a while and thus has no latencies, it will get dropped from the list and thus my selection of it will be lost. It would be nice if in that case a selected application would stay visible and selected, or maybe get reselected automatically when it appears again. Thanks, FJP -- 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/
From: Benjamin Herrenschmidt on 16 Sep 2009 21:40 On Wed, 2009-09-16 at 20:27 +0200, Frans Pop wrote: > Benjamin Herrenschmidt wrote: > > I'll have a look after the merge window madness. Multiple windows is > > also still an option I suppose even if i don't like it that much: we > > could support double-click on an app or "global" in the left list, > > making that pop a new window with the same content as the right pane for > > that app (or global) that updates at the same time as the rest. > > I have another request. If I select a specific application to watch (say a > mail client) but it is idle for a while and thus has no latencies, it will > get dropped from the list and thus my selection of it will be lost. > > It would be nice if in that case a selected application would stay visible > and selected, or maybe get reselected automatically when it appears again. Hrm... I though I forced the selected app to remain ... or maybe I wanted to do that and failed :-) Ok. On the list. Please ping me next week if nothing happens. Ben. -- 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/
From: Ingo Molnar on 18 Sep 2009 07:30 * Michael Buesch <mb(a)bu3sch.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. Ingo -- 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/
From: Felix Fietkau on 18 Sep 2009 10:50
Ingo Molnar wrote: > * Michael Buesch <mb(a)bu3sch.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(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/ |