From: Con Kolivas <kernel@kolivas.org>
To: Matt Mackall <mpm@selenic.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, akpm@linux-foundation.org
Subject: Re: 2.6.21-rc3-mm1 RSDL results
Date: Sat, 10 Mar 2007 08:07:43 +1100 [thread overview]
Message-ID: <200703100807.43582.kernel@kolivas.org> (raw)
In-Reply-To: <20070309204623.GE10394@waste.org>
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
next prev parent reply other threads:[~2007-03-09 21:08 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-09 5:39 2.6.21-rc3-mm1 RSDL results Matt Mackall
2007-03-09 6:28 ` Con Kolivas
2007-03-09 7:53 ` Matt Mackall
2007-03-09 8:20 ` Matt Mackall
2007-03-09 8:39 ` Con Kolivas
2007-03-09 18:27 ` Matt Mackall
2007-03-09 20:15 ` Con Kolivas
2007-03-09 20:26 ` Con Kolivas
2007-03-09 20:51 ` Matt Mackall
2007-03-09 20:55 ` Matt Mackall
2007-03-09 20:46 ` Matt Mackall
2007-03-09 21:07 ` Con Kolivas [this message]
2007-03-09 21:19 ` Con Kolivas
2007-03-09 21:39 ` Matt Mackall
2007-03-09 21:57 ` Con Kolivas
2007-03-09 22:18 ` Con Kolivas
2007-03-09 22:29 ` Matt Mackall
2007-03-09 23:02 ` Con Kolivas
2007-03-09 23:06 ` Matt Mackall
2007-03-10 0:31 ` Con Kolivas
2007-03-10 0:34 ` Con Kolivas
2007-03-10 0:49 ` Matt Mackall
2007-03-10 1:28 ` Con Kolivas
2007-03-10 1:42 ` Matt Mackall
2007-03-10 2:10 ` Kyle Moffett
2007-03-10 2:20 ` Con Kolivas
2007-03-10 2:26 ` Matt Mackall
2007-03-10 2:53 ` Con Kolivas
2007-03-09 21:57 ` Willy Tarreau
2007-03-09 22:12 ` Con Kolivas
2007-03-09 22:20 ` Matt Mackall
2007-03-09 22:31 ` Willy Tarreau
2007-03-10 1:02 ` Con Kolivas
2007-03-10 1:10 ` Matt Mackall
2007-03-10 17:01 ` James Cloos
2007-03-10 23:16 ` Con Kolivas
2007-03-11 12:38 ` James Cloos
2007-03-11 12:52 ` Con Kolivas
2007-03-09 21:10 ` Matt Mackall
2007-03-09 8:36 ` Con Kolivas
2007-03-09 9:07 ` Serge Belyshev
2007-03-09 9:49 ` William Lee Irwin III
2007-03-09 10:36 ` Serge Belyshev
2007-03-09 18:07 ` Mark Lord
2007-03-09 18:24 ` Jeffrey Hundstad
2007-03-09 20:23 ` Con Kolivas
2007-03-10 18:21 ` Mark Lord
2007-03-10 23:34 ` Con Kolivas
2007-03-10 23:38 ` Con Kolivas
2007-03-13 18:21 ` Mark Lord
2007-03-13 20:26 ` Con Kolivas
2007-03-13 22:06 ` Mark Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200703100807.43582.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox