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: Felix Fietkau on 19 Sep 2009 16:40 Ingo Molnar wrote: > * Felix Fietkau <nbd(a)openwrt.org> wrote: > >> Ingo Molnar wrote: >> > * Felix Fietkau <nbd(a)openwrt.org> wrote: >> >> I did some tests with BFS v230 vs CFS on Linux 2.6.30 on a different >> >> MIPS device (Atheros AR2317) with 180 MHz and 16 MB RAM. When running >> >> iperf tests, I consistently get the following results when running the >> >> transfer from the device to my laptop: >> >> >> >> CFS: [ 5] 0.0-60.0 sec 107 MBytes 15.0 Mbits/sec >> >> BFS: [ 5] 0.0-60.0 sec 119 MBytes 16.6 Mbits/sec >> >> >> >> The transfer speed from my laptop to the device are the same with BFS >> >> and CFS. I repeated the tests a few times just to be sure, and I will >> >> check vmstat later. >> > >> > Which exact mainline kernel have you tried? For anything performance >> > related running latest upstream -git (currently at 202c467) would be >> > recommended. >> >> I used the OpenWrt-patched 2.6.30. Support for the hardware that I >> tested with hasn't been merged upstream yet. Do you think that the >> scheduler related changes after 2.6.30 are relevant for non-SMP >> performance as well? If so, I'll work on a test with latest upstream >> -git with the necessary patches when I have time for it. > > Dont know - it's hard to tell what happens without basic analysis tools. > Is there _any_ way to profile what happens on that system? (Do hrtimers > work on it that could be used to profile it?) oprofile doesn't have any support for it (mips r4k, no generic perfcounters), the only usable clock source is a simple cpu cycle counter (which is also used for the timer interrupt). - 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/
From: Ingo Molnar on 20 Sep 2009 14:20 * Felix Fietkau <nbd(a)openwrt.org> wrote: > Ingo Molnar wrote: > > * Felix Fietkau <nbd(a)openwrt.org> wrote: > > > >> Ingo Molnar wrote: > >> > * Felix Fietkau <nbd(a)openwrt.org> wrote: > >> >> I did some tests with BFS v230 vs CFS on Linux 2.6.30 on a different > >> >> MIPS device (Atheros AR2317) with 180 MHz and 16 MB RAM. When running > >> >> iperf tests, I consistently get the following results when running the > >> >> transfer from the device to my laptop: > >> >> > >> >> CFS: [ 5] 0.0-60.0 sec 107 MBytes 15.0 Mbits/sec > >> >> BFS: [ 5] 0.0-60.0 sec 119 MBytes 16.6 Mbits/sec > >> >> > >> >> The transfer speed from my laptop to the device are the same with BFS > >> >> and CFS. I repeated the tests a few times just to be sure, and I will > >> >> check vmstat later. > >> > > >> > Which exact mainline kernel have you tried? For anything performance > >> > related running latest upstream -git (currently at 202c467) would be > >> > recommended. > >> > >> I used the OpenWrt-patched 2.6.30. Support for the hardware that I > >> tested with hasn't been merged upstream yet. Do you think that the > >> scheduler related changes after 2.6.30 are relevant for non-SMP > >> performance as well? If so, I'll work on a test with latest upstream > >> -git with the necessary patches when I have time for it. > > > > Dont know - it's hard to tell what happens without basic analysis tools. > > Is there _any_ way to profile what happens on that system? (Do hrtimers > > work on it that could be used to profile it?) > > oprofile doesn't have any support for it (mips r4k, no generic > perfcounters), the only usable clock source is a simple cpu cycle > counter (which is also used for the timer interrupt). A simple cpu cycle counter ought to be enough to get pretty good perfcounters support going on that box. It takes a surprisingly small amount of code to do that, and a large portion of the perf tooling should then work out of box. Here's a few example commits of minimal perfcounters support, on other architectures: 310d6b6: [S390] wire up sys_perf_counter_open 2d4618d: parisc: perf: wire up sys_perf_counter_open 19470e1: sh: Wire up sys_perf_counter_open. Takes about 15 well placed lines of code, if there are no other complications on MIPS ;-) 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: Frans Pop on 1 Oct 2009 05:40
Benjamin Herrenschmidt wrote: > 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. As requested: ping? And while I'm writing anyway, one more suggestion. I find the fact that the buttons jump twice every 30 seconds (because of a change in the timer between <10 and >=10 seconds) slightly annoying. Any chance of making the position of the buttons fixed? One option could be moving the timer to the left side of the bottom bar. Cheers, 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/ |