Messages in this thread | | | Date | Tue, 08 Sep 2009 21:15:22 +0300 | From | Nikos Chantziaras <> | Subject | Re: BFS vs. mainline scheduler benchmarks and measurements |
| |
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
| |