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: Michael Buesch on 8 Sep 2009 11:50 On Monday 07 September 2009 22:57:01 Ingo Molnar wrote: > > * Michael Buesch <mb(a)bu3sch.de> wrote: > > > On Monday 07 September 2009 20:26:29 Ingo Molnar wrote: > > > Could you profile it please? Also, what's the context-switch rate? > > > > As far as I can tell, the broadcom mips architecture does not have > > profiling support. It does only have some proprietary profiling > > registers that nobody wrote kernel support for, yet. > > Well, what does 'vmstat 1' show - how many context switches are > there per second on the iperf server? In theory if it's a truly > saturated box, there shouldnt be many - just a single iperf task > running at 100% CPU utilization or so. > > (Also, if there's hrtimer support for that board then perfcounters > could be used to profile it.) CFS: procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 15892 1684 5868 0 0 0 0 268 6 31 69 0 0 1 0 0 15892 1684 5868 0 0 0 0 266 2 34 66 0 0 1 0 0 15892 1684 5868 0 0 0 0 266 6 33 67 0 0 1 0 0 15892 1684 5868 0 0 0 0 267 4 37 63 0 0 1 0 0 15892 1684 5868 0 0 0 0 267 6 34 66 0 0 [ 4] local 192.168.1.1 port 5001 connected with 192.168.1.99 port 47278 2 0 0 15756 1684 5868 0 0 0 0 1655 68 26 74 0 0 2 0 0 15756 1684 5868 0 0 0 0 1945 88 20 80 0 0 2 0 0 15756 1684 5868 0 0 0 0 1882 85 20 80 0 0 2 0 0 15756 1684 5868 0 0 0 0 1923 86 18 82 0 0 2 0 0 15756 1684 5868 0 0 0 0 1986 87 23 77 0 0 2 0 0 15756 1684 5868 0 0 0 0 1923 87 17 83 0 0 2 0 0 15756 1684 5868 0 0 0 0 1951 84 19 81 0 0 2 0 0 15756 1684 5868 0 0 0 0 1970 87 18 82 0 0 2 0 0 15756 1684 5868 0 0 0 0 1972 85 23 77 0 0 2 0 0 15756 1684 5868 0 0 0 0 1961 87 18 82 0 0 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 28.6 MBytes 23.9 Mbits/sec 1 0 0 15752 1684 5868 0 0 0 0 599 22 22 78 0 0 1 0 0 15752 1684 5868 0 0 0 0 269 4 32 68 0 0 1 0 0 15752 1684 5868 0 0 0 0 266 4 29 71 0 0 1 0 0 15764 1684 5868 0 0 0 0 267 6 37 63 0 0 1 0 0 15764 1684 5868 0 0 0 0 267 4 31 69 0 0 1 0 0 15768 1684 5868 0 0 0 0 266 4 51 49 0 0 I'm currently unable to test BFS, because the device throws strange flash errors. Maybe the flash is broken :( -- Greetings, Michael. -- 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: Nikos Chantziaras on 8 Sep 2009 14:20 On 09/07/2009 02:01 PM, Frederic Weisbecker wrote: > On Mon, Sep 07, 2009 at 06:38:36AM +0300, Nikos Chantziaras wrote: >> Unfortunately, I can't come up with any way to somehow benchmark all of >> this. There's no benchmark for "fluidity" and "responsiveness". Running >> the Doom 3 benchmark, or any other benchmark, doesn't say anything about >> responsiveness, it only measures how many frames were calculated in a >> specific period of time. How "stable" (with no stalls) those frames were >> making it to the screen is not measurable. > > > That looks eventually benchmarkable. This is about latency. > For example, you could try to run high load tasks in the > background and then launch a task that wakes up in middle/large > periods to do something. You could measure the time it takes to wake > it up to perform what it wants. > > We have some events tracing infrastructure in the kernel that can > snapshot the wake up and sched switch events. > > Having CONFIG_EVENT_TRACING=y should be sufficient for that. > > You just need to mount a debugfs point, say in /debug. > > Then you can activate these sched events by doing: > > echo 0> /debug/tracing/tracing_on > echo 1> /debug/tracing/events/sched/sched_switch/enable > echo 1> /debug/tracing/events/sched/sched_wake_up/enable > > #Launch your tasks > > echo 1> /debug/tracing/tracing_on > > #Wait for some time > > echo 0> /debug/tracing/tracing_off > > That will require some parsing of the result in /debug/tracing/trace > to get the delays between wake_up events and switch in events > for the task that periodically wakes up and then produce some > statistics such as the average or the maximum latency. > > That's a bit of a rough approach to measure such latencies but that > should work. I've tried this with 2.6.31-rc9 while running mplayer and alt+tabbing repeatedly to the point where mplayer starts to stall and drop frames. This produced a 4.1MB trace file (132k bzip2'ed): http://foss.math.aegean.gr/~realnc/kernel/trace1.bz2 Uncompressed for online viewing: http://foss.math.aegean.gr/~realnc/kernel/trace1 I must admit that I don't know what it is I'm looking at :P -- 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: Nikos Chantziaras on 8 Sep 2009 15:10 On 09/08/2009 02:35 PM, Ingo Molnar wrote: > > * Nikos Chantziaras<realnc(a)arcor.de> wrote: > >> [...] That would mean that you (or anyone else with an interest of >> tracking this down) would follow the examples given (by me and >> others, like enabling desktop compositing, firing up mplayer with >> a video and generally reproducing this using the quite detailed >> steps I posted as a recipe). > > Could you follow up on Frederic's detailed tracing suggestions that > would give us the source of the latency? I've set it up and ran the tests now. > ( Also, as per lkml etiquette, please try to keep the Cc: list > intact when replying to emails. I missed your first reply > that you un-Cc:-ed. ) Sorry for that. > A quick look at the latencytop output suggests a scheduling latency. > Could you send me the kernel .config that you are using? That would be this one: http://foss.math.aegean.gr/~realnc/kernel/config-2.6.31-rc9 -- 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 8 Sep 2009 16:30 Arjan van de Ven wrote: > the latest version of latencytop also has a GUI (thanks to Ben) That looks nice, but... I kind of miss the split screen feature where latencytop would show both the overall figures + the ones for the currently most affected task. Downside of that last was that I never managed to keep the display on a specific task. The graphical display also makes it impossible to simply copy and paste the results. Having the freeze button is nice though. Would it be possible to have a command line switch that allows to start the old textual mode? Looks like the man page needs updating too :-) 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/
From: Jens Axboe on 8 Sep 2009 16:40
On Tue, Sep 08 2009, Peter Zijlstra wrote: > On Tue, 2009-09-08 at 11:13 +0200, Jens Axboe wrote: > > And here's a newer version. > > I tinkered a bit with your proglet and finally found the problem. > > You used a single pipe per child, this means the loop in run_child() > would consume what it just wrote out until it got force preempted by the > parent which would also get woken. > > This results in the child spinning a while (its full quota) and only > reporting the last timestamp to the parent. Oh doh, that's not well thought out. Well it was a quick hack :-) Thanks for the fixup, now it's at least usable to some degree. > Since consumer (parent) is a single thread the program basically > measures the worst delay in a thundering herd wakeup of N children. Yes, it's really meant to measure how long it takes to wake a group of processes, assuming that this is where things fall down on the 'box loaded, switch desktop' case. Now whether that's useful or not or whether this test app is worth the bits it takes up on the hard drive, is another question. -- Jens Axboe -- 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/ |