On Saturday 10 March 2007 07:46, Matt Mackall wrote: > Ok, I've now disabled sched_yield (I'm using xorg radeon drivers).
Great. > 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 It's sad that sched_yield is still in our graphics card drivers ... > 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. Ah that's some nice detective work there. Mainline does some rather complex accounting on sched_fork including (possibly) a whole timer tick which rsdl does not do. make forks off continuously so what you say may well be correct. I'll see if I can try to revert to the mainline behaviour in sched_fork (which was obviously there for a reason). -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
