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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.