[Gllug] Tuning the CPU scheduler

[- Tethys]

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.

> 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. To be fair, the audio stutters are fairly minimal, and I think
they might be a red herring. Most of my problems are with slow window
redraws, slow responses to keyboard/mouse events and the like. The
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
anything else. My audio stutters if I switch to VT1 and stops
altogether if I switch to any other VT. 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.

> Talk to the scheduler hackers then, and see what they say. The scheduler
> is insanely tunable these days.

Like I said, I know! I just don't know the details...

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

	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
	fpu             : yes
	fpu_exception   : yes
	cpuid level     : 1
	wp              : yes
	flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow rep_good extd_apicid pni lahf_lm
	bogomips        : 4420.39
	TLB size        : 1024 4K pages
	clflush size    : 64
	cache_alignment : 64
	address sizes   : 40 bits physical, 48 bits virtual
	power management: ts fid vid ttp

> 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. Nor do I have the
time right now to regression test a bunch of kernels to see if I can
find the commit which made things worse (assuming there's just one, of
course).

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 :-(

Tet

-- 
“It seems intuitively obvious to me, which means that it might be
wrong.” -- Chris Torek
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug