Re: BFS vs. mainline scheduler benchmarks and measurements

[Martin Steigerwald]

Uhoh, it seems I configured my kernel's scheduler to produce keyboard 
failure. The many o's in my last mails where not intended.

Let's see whether its better with:

shambhala:/proc/sys/kernel> echo 2000000 > 
/proc/sys/kernel/sched_wakeup_granularity_ns

First time I just lost the keyboard in X for a while in such a way that 
even a Strg-Alt-F1 did not yield any effect. None of what I typed appeared 
anywhere, not in the mail composer window nor in a Konsole terminal or in 
the Kickoff menu search field. Mouse still worked okay. I was able to log 
out via mouse. Then even in KDM the keyboard did not work. Suddenly it 
produced repeating key input events without me typing anything anymore. 
Like the second time with those o's where I pressed on send instead of 
save as draft accidentally.

I did not have any keyboard issues like this recently nor in the last year 
or longer. Let's see whether that raised wakeup_granulaty helps. Desktop 
experience seems still quite fluid, maybe not as fluid as with the settings 
below. But I prefer a working keyboard in order to finish up this mail.

Am Donnerstag 10 September 2009 schrieb Ingo Molnar:
> * Martin Steigerwald <Martin@xxxxxxxxxxxx> 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 just saw two to five steps of the animation, 
now its really a lot more fluid. 

perceived _latency--! Well its like opening 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 


01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 
[Mobility Radeon 9600 M10] [1002:4e50]
(with OSS Radeon driver)

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 [2nd keyboard borkage, somewhere before where the first 
where I saved as draft] for that operating system. So actually I knew 
there could be less waiting and less latency. (Granted AmigaOS 4.1 is much 
more minimalistic also in terms on features and no complete memory 
protection and message passing by exchanging pointers and whatnot).

At least to summarize this: With those settings I just keep switching 
desktops and opening windows to enjoy the effects. Desktops flip over 
fluently and windows zoom in on opening fluently either.

All those experiences are with:

shambhala:~> cat /proc/version
Linux version 2.6.31-rc7-tp42-toi-3.0.1-04741-g57e61c0 (martin@shambhala) 
(gcc version 4.3.3 (Debian 4.3.3-10) ) #6 PREEMPT Sun Aug 23 10:51:32 CEST 
2009

(Nigel Cunningham's tuxonice-head git from about 10 days ago)

Keyboard still working. Possibly it really has got broken with zero as 
wakeup granularity.

> > 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?

Hmmm, would there be a simple possibilty to somehow merge tuxonice git and 
your tip.git into a nice TuxOnIce + scheduler enhanced kernel? I do tend 
not to stick with non TuxOnIce enabled kernels for too long. At least not 
on my work thinkpad and my Amarok thinkpad cause I believe that reboots 
are just for kernel upgrades (with API changes that is) ;-).

Apart from that I lack time to compile a kernel a day at the moment like 
in good old RSDL, SD and CFS testing times ;-). But next kernel, 2.6.31-
not-a-rc, is due and I take suggestions for that one. Preferably I would 
like to have it with TuxOnIce tough.

Problems I faced:

1) Well those effect issues. Jerky at best. Animations which should have 
had 25 frames per second at least, showed 2-5 frames a second. Above 
tuning helped a lot with that. On the other hand DVD playback with Dragon 
Player (and Xine) seems just fine - I thought at least. Maybe I should 
compare watching StarTrek NG with and without scheduler latency fixes. And 
maybe I find some additional frames per duration there too.

2) Some jerks here and there. Difficult to categorize. It sometimes just 
happens that the machine does not follow where I put my attention. Like a 
distracted human who has other things to do than listening to me. This 
could be trying to enter some text in a Qt text input widget. But I need 
to look more carefully as to when, where and why. This is just too fuzzy.

3) Sometimes even typing as a visible latency. Its difficult to spot the 
cause for that stuff. When I type I expect to see each letter as I type it.

4) I/O latencies causing the machine to actually stall for seconds. But 
this one got much better when I switched to 2.6.31 - I had to skip 2.6.30 
cause it didn't tuxonice nicely, even 2.6.31 did not until it reached rc5. 
It seems even way better after switching from XFS to Ext4. But well that 
is a different issue. And at the moment I am quite happy with that.

5) Some window manager operations like resizing windows take very long 
with compositing. But I think this issue may lie elsewhere. Cause these 
did not improve with above settings while many compositing effects did. I 
dunno where that slow window resizing comes from. Whether its a 
compositing / KWin / Qt refresh issue or something scheduler or something 
gfx driver related.

Keyboard is still working, yay! So the X.org keyboard driver might get 
irritated with zero as wakeup granularity.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Attachment: signature.asc
Description: This is a digitally signed message part.