Re: 2.6.21-rc3-mm1 RSDL results

Con Kolivas
2007-03-09T21:08:05Z

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