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: Ingo Molnar on 10 Sep 2009 16:10 * Martin Steigerwald <Martin(a)lichtvoll.de> wrote: > Am Mittwoch 09 September 2009 schrieb Peter Zijlstra: > > On Wed, 2009-09-09 at 12:05 +0300, Nikos Chantziaras wrote: > > > Thank you for mentioning min_granularity. After: > > > > > > echo 10000000 > /proc/sys/kernel/sched_latency_ns > > > echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns > > > > You might also want to do: > > > > echo 2000000 > /proc/sys/kernel/sched_wakeup_granularity_ns > > > > That affects when a newly woken task will preempt an already running > > task. > > Heh that scheduler thing again... and unfortunately Col appearing > to feel hurt while I am think that Ingo is honest on his offer on > collaboration... > > While it makes fun playing with that numbers and indeed > experiencing subjectively a more fluid deskopt how about just a > > echo "This is a f* desktop!" > /proc/sys/kernel/sched_workload No need to do that, that's supposed to be the default :-) The knobs are really just there to help us make it even more so - i.e. you dont need to tune them. But it really relies on people helping us out and tell us which combinations work best ... > Or to say it in other words: The Linux kernel should not require > me to fine-tune three or more values to have the scheduler act in > a way that matches my workload. > > I am willing to test stuff on my work thinkpad and my Amarok > thinkpad in order to help improving with that. It would be great if you could check latest -tip: http://people.redhat.com/mingo/tip.git/README and compare it to vanilla .31? Also, could you outline the interactivity problems/complaints you have? 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: Frederic Weisbecker on 10 Sep 2009 16:30 On Tue, Sep 08, 2009 at 09:15:22PM +0300, Nikos Chantziaras wrote: > On 09/07/2009 02:01 PM, Frederic Weisbecker wrote: >> 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 Hehe :-) Basically you have samples of two kind of events: - wake up (when thread A wakes up B) The format is as follows: task-pid (the waker A) | | cpu timestamp event-name wakee(B) prio status | | | | | | | X-11482 [001] 1023.219246: sched_wakeup: task kwin:11571 [120] success=1 Here X is awakening kwin. - sched switch (when the scheduler stops A and launches B) A, task B, task that gets that gets sched sched out in A cpu timestamp event-name | A prio | B prio | | | | | | | | X-11482 [001] 1023.219247: sched_switch: task X:11482 [120] (R) ==> kwin:11571 [120] | | State of A For A state we can have either: R: TASK_RUNNING, the task is not sleeping but it is rescheduled for later to let another task run S: TASK_INTERRUPTIBLE, the task is sleeping, waiting for an event that may wake it up. The task can be waked by a signal D: TASK_UNINTERRUPTIBLE, same as above but can't be waked by a signal. Now what could be interesting interesting is to measure the time between such pair of events: - t0: A wakes up B - t1: B is sched in t1 - t0 would then be the scheduler latency, or at least part of it: The scheduler latency may be an addition of several factors: - the time it takes for the actual wake up to perform (re-insert the task into a runqueue, which can be subject to the runqueue(s) design, the rebalancing if needed, etc.. - the time between a task is waked up and the scheduler eventually decide to schedule it in. - the time it takes to perform the task switch, which is not only in the scheduler scope. But the time it takes may depend of a rebalancing decision (cache cold, etc..) Unfortunately we can only measure the second part with the above ftrace events. But that's still an interesting scheduler abstract that is a large part of the scheduler latency. We could write a tiny parser that could walk through such ftrace traces and produce some average, maximum, standard deviation numbers. But we have userspace tools that can parse ftrace events (through perf counter), so I'm trying to write something there, hopefully I could get a relevant end result. Thanks. -- 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 10 Sep 2009 16:50 * Martin Steigerwald <Martin(a)lichtvoll.de> wrote: > Am Donnerstag 10 September 2009 schrieb Ingo Molnar: > > * Martin Steigerwald <Martin(a)lichtvoll.de> wrote: > > > Am Mittwoch 09 September 2009 schrieb Peter Zijlstra: > > > > On Wed, 2009-09-09 at 12:05 +0300, Nikos Chantziaras wrote: > > > > > Thank you for mentioning min_granularity. After: > > > > > > > > > > echo 10000000 > /proc/sys/kernel/sched_latency_ns > > > > > echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns > > > > > > > > You might also want to do: > > > > > > > > echo 2000000 > /proc/sys/kernel/sched_wakeup_granularity_ns > > > > > > > > That affects when a newly woken task will preempt an already > > > > running task. > > > > > > Heh that scheduler thing again... and unfortunately Col appearing > > > to feel hurt while I am think that Ingo is honest on his offer on > > > collaboration... > > > > > > While it makes fun playing with that numbers and indeed > > > experiencing subjectively a more fluid deskopt how about just a > > > > > > echo "This is a f* desktop!" > /proc/sys/kernel/sched_workload > > > > No need to do that, that's supposed to be the default :-) The knobs > > are really just there to help us make it even more so - i.e. you > > dont need to tune them. But it really relies on people helping us > > out and tell us which combinations work best ... > > Well currently I have: > > shambhala:/proc/sys/kernel> grep "" sched_latency_ns > sched_min_granularity_ns sched_wakeup_granularity_ns > sched_latency_ns:100000 > sched_min_granularity_ns:200000 > sched_wakeup_granularity_ns:0 > > And this give me *a completely different* desktop experience. 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. 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: Martin Steigerwald on 10 Sep 2009 16:50 Am Donnerstag 10 September 2009 schrieb Ingo Molnar: > * Martin Steigerwald <Martin(a)lichtvoll.de> wrote: > > Am Mittwoch 09 September 2009 schrieb Peter Zijlstra: > > > On Wed, 2009-09-09 at 12:05 +0300, Nikos Chantziaras wrote: > > > > Thank you for mentioning min_granularity. After: > > > > > > > > echo 10000000 > /proc/sys/kernel/sched_latency_ns > > > > echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns > > > > > > You might also want to do: > > > > > > echo 2000000 > /proc/sys/kernel/sched_wakeup_granularity_ns > > > > > > That affects when a newly woken task will preempt an already > > > running task. > > > > Heh that scheduler thing again... and unfortunately Col appearing > > to feel hurt while I am think that Ingo is honest on his offer on > > collaboration... > > > > While it makes fun playing with that numbers and indeed > > experiencing subjectively a more fluid deskopt how about just a > > > > echo "This is a f* desktop!" > /proc/sys/kernel/sched_workload > > No need to do that, that's supposed to be the default :-) The knobs > are really just there to help us make it even more so - i.e. you > dont need to tune them. But it really relies on people helping us > out and tell us which combinations work best ... Well currently I have: shambhala:/proc/sys/kernel> grep "" sched_latency_ns sched_min_granularity_ns sched_wakeup_granularity_ns sched_latency_ns:100000 sched_min_granularity_ns:200000 sched_wakeup_granularity_ns:0 And this give me *a completely different* desktop experience. I am using KDE 4.3.1 on a mixture of Debian Squeeze/Sid/Experimental, with compositing. And now when I flip desktops or open a window I can *actually see* the animation. Before I jusooooooooooooooooooooot saw two to five steps of the animation, now its really a lot more fluid. perceived _latency--! Well its like oooooooooooooooooooooooooooooooooooooooooooooooooooooooopening the eyes again cause I tended to take the jerky behavior as normal and possibly related to having KDE 4.3.1 with compositing enabled on a ThinkPad T42 with ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50] which I consider to be low end for that workload. But then why actually? Next to me is a Sam440ep with PPC 440 667 MHz and and even older Radeon M9 with AmigaOS 4.1 and some simple transparency effects with compositing. And well this combo does feel like it wheel spins cause the hardware is actually to fast foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > Or to say it in other words: The Linux kernel should not require > > me to fine-tune three or more values to have the scheduler act in > > a way that matches my workload. > > > > I am willing to test stuff on my work thinkpad and my Amarok > > thinkpad in order to help improving with that. > > It would be great if you could check latest -tip: > > http://people.redhat.com/mingo/tip.git/README > > and compare it to vanilla .31? > > Also, could you outline the interactivity problems/complaints you > have? > > 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/ > -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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: Martin Steigerwald on 10 Sep 2009 17:20
Am Donnerstag 10 September 2009 schrieb Ingo Molnar: > * Martin Steigerwald <Martin(a)lichtvoll.de> wrote: > > Am Donnerstag 10 September 2009 schrieb Ingo Molnar: > > > * Martin Steigerwald <Martin(a)lichtvoll.de> wrote: > > > > Am Mittwoch 09 September 2009 schrieb Peter Zijlstra: > > > > > On Wed, 2009-09-09 at 12:05 +0300, Nikos Chantziaras wrote: > > > > > > Thank you for mentioning min_granularity. After: > > > > > > > > > > > > echo 10000000 > /proc/sys/kernel/sched_latency_ns > > > > > > echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns > > > > > > > > > > You might also want to do: > > > > > > > > > > echo 2000000 > > > > > > /proc/sys/kernel/sched_wakeup_granularity_ns > > > > > > > > > > That affects when a newly woken task will preempt an already > > > > > running task. > > > > > > > > Heh that scheduler thing again... and unfortunately Col appearing > > > > to feel hurt while I am think that Ingo is honest on his offer on > > > > collaboration... > > > > > > > > While it makes fun playing with that numbers and indeed > > > > experiencing subjectively a more fluid deskopt how about just a > > > > > > > > echo "This is a f* desktop!" > /proc/sys/kernel/sched_workload > > > > > > No need to do that, that's supposed to be the default :-) The knobs > > > are really just there to help us make it even more so - i.e. you > > > dont need to tune them. But it really relies on people helping us > > > out and tell us which combinations work best ... > > > > Well currently I have: > > > > shambhala:/proc/sys/kernel> grep "" sched_latency_ns > > sched_min_granularity_ns sched_wakeup_granularity_ns > > sched_latency_ns:100000 > > sched_min_granularity_ns:200000 > > sched_wakeup_granularity_ns:0 > > > > And this give me *a completely different* desktop experience. > > 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. Hmmm, need to mount that first. But not today, cause I have to dig out on how to do it. Have to pack some things for tomorrow. And then sleep time. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 |