From: Mike Galbraith <efault@gmx.de>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Ingo Molnar <mingo@elte.hu>, Daniel Walker <dwalker@mvista.com>,
linux-kernel@vger.kernel.org, peterz@infradead.org
Subject: Re: [ANNOUNCE/RFC] Really Fair Scheduler
Date: Sat, 08 Sep 2007 09:56:48 +0200 [thread overview]
Message-ID: <1189238208.6575.54.camel@Homer.simpson.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0709071634450.1817@scrub.home>
On Fri, 2007-09-07 at 17:35 +0200, Roman Zippel wrote:
> Hi,
>
> On Sun, 2 Sep 2007, Ingo Molnar wrote:
>
> Below is a patch updated against the latest git tree, no major changes.
Interesting, I see major behavioral changes.
I still see an aberration with fairtest2. On startup, the hog component
will consume 100% cpu for a bit, then the sleeper shows up. This
doesn't always happen, but happens quite often. The time it takes for
the sleeper to show up varies, but is roughly as below. With the
previous kernel, sleeper starvation was permanent once the hog ran for a
bit. This behavior inverted itself, starvation now goes away after a
bit.
6573 root 20 0 1568 468 384 R 51 0.0 0:08.30 1 fairtest2
6574 root 20 0 1568 112 28 R 47 0.0 0:01.07 1 fairtest2
Once it coughs up it's fairtest2 startup-furball, it does well on mixed
load (various interval sleepers + hog) fairness. The previous kernel
did not do at all well at mixed load, as soon as I added a hog, it was
all over for sleepers, and even without a hog, fairness among the
various interval sleepers was not at all good.
On the interactivity front, your first cut was not really usable here,
but this one seems fine <not heavily tested caveat>. One test I do here
is Amarok song switch time under hefty kbuild load, and this kernel
passes that test just fine. I didn't try this test with your first cut,
because it was very ragged even under modest load. All in all, this one
is behaving quite well, which is radically different than my experience
with first cut.
Debug messages triggered on boot, but haven't triggered since.
[ 113.426575] audit(1189232695.670:2): audit_backlog_limit=256 old=64 by auid=4294967295 res=1
[ 113.953958] IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
[ 115.851209] audit(1189232698.095:3): audit_pid=5597 old=0 by auid=4294967295
[ 116.707631] 2,f73035a0(5624): 1fa78027f5c,1fb37ff0000,f7d035a0(5626),1
[ 116.723091] WARNING: at kernel/sched_norm.c:243 verify_queue()
[ 116.737979] [<c0105188>] show_trace_log_lvl+0x1a/0x30
[ 116.752191] [<c0105d83>] show_trace+0x12/0x14
[ 116.765544] [<c0105d9b>] dump_stack+0x16/0x18
[ 116.778579] [<c011e489>] verify_queue+0x158/0x388
[ 116.791716] [<c011e6db>] enqueue_entity+0x22/0x19a
[ 116.804880] [<c011e9e2>] task_new_fair+0xa9/0xd2
[ 116.817724] [<c0123c47>] wake_up_new_task+0x9e/0xad
[ 116.830723] [<c0125ddc>] do_fork+0x13c/0x205
[ 116.843063] [<c0102258>] sys_clone+0x33/0x39
[ 116.855353] [<c0104182>] sysenter_past_esp+0x5f/0x85
[ 116.868344] =======================
[ 116.879674] 2,f7303ae0(5618): 1fbf7fca89d,1fb37ff0000,f7d035a0(5626),1
[ 116.894100] WARNING: at kernel/sched_norm.c:250 verify_queue()
[ 116.907863] [<c0105188>] show_trace_log_lvl+0x1a/0x30
[ 116.920912] [<c0105d83>] show_trace+0x12/0x14
[ 116.933141] [<c0105d9b>] dump_stack+0x16/0x18
[ 116.945361] [<c011e5b9>] verify_queue+0x288/0x388
[ 116.957945] [<c011e6db>] enqueue_entity+0x22/0x19a
[ 116.970363] [<c011e9e2>] task_new_fair+0xa9/0xd2
[ 116.982308] [<c0123c47>] wake_up_new_task+0x9e/0xad
[ 116.994597] [<c0125ddc>] do_fork+0x13c/0x205
[ 117.006331] [<c0102258>] sys_clone+0x33/0x39
[ 117.017848] [<c0104182>] sysenter_past_esp+0x5f/0x85
[ 117.029869] =======================
<repeats dozen times or so>
next prev parent reply other threads:[~2007-09-08 7:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-31 2:05 Roman Zippel
2007-08-31 9:36 ` Mike Galbraith
2007-08-31 13:22 ` Roman Zippel
2007-08-31 13:55 ` Mike Galbraith
2007-09-01 4:35 ` Mike Galbraith
2007-08-31 10:54 ` Ingo Molnar
2007-08-31 13:19 ` Roman Zippel
2007-09-02 9:26 ` Ingo Molnar
2007-09-03 2:58 ` Roman Zippel
2007-09-06 3:03 ` Syren Baran
2007-09-01 6:48 ` Roman Zippel
2007-09-02 2:19 ` Bill Davidsen
2007-09-02 17:02 ` Roman Zippel
2007-09-02 0:52 ` Daniel Walker
2007-09-02 7:20 ` Ingo Molnar
2007-09-02 8:40 ` Satyam Sharma
2007-09-02 9:59 ` Ingo Molnar
2007-09-02 15:16 ` Roman Zippel
2007-09-02 15:29 ` Ingo Molnar
2007-09-02 17:16 ` Roman Zippel
2007-09-02 19:21 ` Ingo Molnar
2007-09-07 15:35 ` Roman Zippel
2007-09-08 7:56 ` Mike Galbraith [this message]
2007-09-08 8:23 ` Mike Galbraith
2007-09-10 23:23 ` Roman Zippel
2007-09-11 6:18 ` Mike Galbraith
2007-09-11 11:28 ` Roman Zippel
2007-09-02 14:47 ` Roman Zippel
2007-09-02 15:00 ` Daniel Walker
2007-09-03 18:20 ` Roman Zippel
2007-09-03 21:06 ` Daniel Walker
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=1189238208.6575.54.camel@Homer.simpson.net \
--to=efault@gmx.de \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=zippel@linux-m68k.org \
/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
all inboxes | Powered by JetHome®