[Gllug] Tuning the CPU scheduler

[Nix]

On 28 Oct 2009, tethys at gmail.com outgrape:

> On Tue, Oct 27, 2009 at 9:57 PM, Nix <nix at esperi.org.uk> wrote:
>
>>>                  Now, though, any time you open multiple images in
>>> GIMP, switch to a different tab in Firefox, or even just bring a
>>
>> Both of these apps are single-threaded in critical areas (especially
>> FF, which has single-threaded rendering *and* single-threaded JS to
>> contend with).
>
> Agreed. I *know* the applications are partially to blame. But my gut
> feeling is that things are worse than they were, say 12 months ago,
> and I don't believe that's solely down to application bloat.

Not if you're using xmms. It hasn't bloated: it's dead!

(But yes, the kernel's icache footprint is horrid, Linus has said as
much. How the hell to get it down is another matter. Features have to
have some icache cost.)

>> OK, that's problematic (and very surprising, as most of the media layer
>> shold be running with realtime priority, if your rlimits are set to
>> allow it. PulseAudio does, mpd does... mpg123 doesn't. What are you
>> playing music with?)
>
> xmms.

So you're playing music with a music player that's been maintenance-dead
for over half a *decade*, that among other things doesn't do much to try
to tell the scheduler to use realtime response (though at least it tries
to bump its nice level up), whose buffering is a byword for brokenness,
and you're surprised it's stuttering?

I hope at least you're using ALSA for sound output and not esound or
OSS. (However, that's not going to help much as xmms doesn't bother
to adjust the alsa buffer sizes from their default.)

Use a music player that isn't a vast heap of steaming donkey manure from
the late 1990s and things might improve.

>       To be fair, the audio stutters are fairly minimal, and I think
> they might be a red herring.

I bet xmms is to blame. (I don't like xmms much. The code sucks and the
user interface is unbelievably vile.)

>                              Most of my problems are with slow window
> redraws, slow responses to keyboard/mouse events and the like. The

Interesting. Given your CPU specs below, well, I didn't have slow
responses to anything on a machine half that speed except when it was
swapping.

> only reproducible audio case I can find is switching to another VT and
> I think that's due to the braindead design of PulseAudio more than

PA doesn't care if you switch VTs. (Why would it?)

> anything else. My audio stutters if I switch to VT1 and stops

Modesetting on many video cards includes long periods of busywaiting in
the X server, but that should only busy out one core. KMS fixes this, as
you no longer change video modes at all except at startup. (Also you get
a framebuffer console with heaps of lines and columns that doesn't slow
X down, at *last*. X doesn't yet quite run as non-root but we're very
near now.)

> altogether if I switch to any other VT.

WT*F*?

>                                         For me, audio should be a
> system wide thing. I *want* to be able to set some music playing in
> the background, switch to a different VT and do stuff while still
> listening to my music.

Agreed, and I can. (I can't play music without X running at all, because
PA is started by my .Xinitrc. But that's OK, X is running the vast
majority of the time for me. If you want to avoid all this, run PA as a
systemwide daemon: but this isn't done by default because a lot of per-
user setting stuff stops working if you do that, and because local sound
data transfer can no longer use SHM but must be serialized over a
network socket, even locally.)

Your distro has done something seriously weird, and I can't immediately
see what it could be. Maybe X and all its clients actually freeze when
you switch away? (They shouldn't. It should be easy enough to check
this.)

>>> So basically, does anyone know what I should be tuning and how I
>>> should be tuning it in order to improve responsiveness on a desktop
>>> machine?
>>
>> Is the machine/kernel SMP, hyperthreaded, PREEMPT, PREEMPT_VOLUNTARY,
>> -rt, what? What architecture is it?
>
> Stock Fedora 11 kernel (kernel-2.6.30.8-64.fc11.x86_64). SMP. Two of these:

Oh god, distro patched hell. Report to Fedora then :(((

> 	processor       : 0
> 	vendor_id       : AuthenticAMD
> 	cpu family      : 15
> 	model           : 37
> 	model name      : AMD Opteron(tm) Processor 248
> 	stepping        : 1
> 	cpu MHz         : 2210.195
> 	cache size      : 1024 KB

Pretty nippy and with a fairly good cache then. You certainly shouldn't
see skipping on this unless you're swapping.

> 	power management: ts fid vid ttp

oo oo oo! I don't know what any of these are, but what about CPU
frequency scaling and other power management stuff? Got anything like
that running? Some of the nastier power management things can *really*
do bad things to interactive response :/

>> You've given us pretty much nothing to go on here. (Also this is the
>> wrong list. l-k is hardly obscure.)
>
> The problem with l-k is that I know the very first question I'll be
> asked by Ingo et al is if I can provide a reproducible test case,
> which I can't. The system *feels* more sluggish.

latencytop still might be helpful if you do get intermittent stalls
or something like that.

> So I thought I'd ask here and see if anyone knew of a quick win tweak
> to the scheduling parameters that might improve things. Sadly it's
> looking like the answer to that is no :-(

Nah, there are too many variables here :(((
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug