On Fri, Mar 09, 2007 at 07:39:05PM +1100, Con Kolivas wrote:
Ok, I've now disabled sched_yield (I'm using xorg radeon drivers).
So far:
rc2-mm2 RSDL RSDL+NO_HZ RSDL+NO_HZ+no_yield estimated CPU
no load
beryl good good great great ~30% at 600MHz
galeon good good good good 100% at 600MHz
mp3 good good good good < 5% at 600MHz
terminal good good good good ~0
mouse good good good good ~0
make
beryl awful ok good
galeon bad ok good
mp3 good good good
terminal bad good good
mouse bad good good
make -j2
beryl awful bad/ok
metacity bad/ok <- it's not beryl-specifc
galeon bad bad/ok
mp3 good good
terminal bad bad/ok
mouse bad bad/ok
make -j5
beryl ok awful awful awful/bad
galeon ok bad bad bad
mp3 good good good a couple skips
terminal ok bad bad bad
mouse good bad bad bad
memload x5
beryl ok/good
galeon ok/good
mp3 good
terminal ok/good
mouse ok/good
good = no problems
ok = noticeable latency
bad = hard to use
awful = completely unusable
By the way, make -j5 is my usual kernel compile because it gives me
the best wall time on this box.
A priori, this load should be manageable by RSDL as the interactive
loads are all pretty small. So I wrote a little Python script that
basically continuously memcpys some 16MB chunks of memory:
#!/usr/bin/python
a = "a" * 16 * 1024 * 1024
while 1:
b = a[1:] + "b"
a = b[1:] + "c"
I've got 1.5G of RAM, so I can run quite a few of these without
killing my pagecache. This should test whether a) Beryl's actually
running up against memory bandwidth issues and b) whether "simple"
static loads work. As you can see, running 5 instances of this script
leaves me in good shape still. 10 is still in "ok" territory, with top
showing each getting 9.7-10% of the CPU. 15 starts to feel sluggish.
20 the mouse jumps a bit and I got an MP3 skip. 30 is getting pretty
bad, but still not as bad as the make -j 5 load.
My suspicion is the problem lies in giving too much quanta to
newly-started processes.
--
Mathematics is the supreme nostalgia of our time.
-