From: Andrew Morton <akpm@osdl.org>
To: Con Kolivas <kernel@kolivas.org>
Cc: piggin@cyberone.com.au, mingo@elte.hu,
linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net
Subject: Re: [PATCH]O18.1int
Date: Sat, 23 Aug 2003 14:49:07 -0700 [thread overview]
Message-ID: <20030823144907.6bcce289.akpm@osdl.org> (raw)
In-Reply-To: <200308240258.33924.kernel@kolivas.org>
Con Kolivas <kernel@kolivas.org> wrote:
>
> > >It might help if you or a buddy could get set up with volanomark on an
> > > OSDL 4-or-8-way so that you can more closely track the effect of your
> > > changes on such benchmarks.
>
> Ok here goes.
> This is on 8way:
>
> Test4:
> Average throughput = 11145 messages per second
>
> Test4-O18.1:
> Average throughput = 9860 messages per second
>
> Test3-mm3:
> Average throughput = 9788 messages per second
>
>
> So I grabbed test3-mm3 and started peeling back the patches
> and found no change in throughput without _any_ of my Oxint patches applied,
> and just Ingo's A3 patch:
>
> Test3-mm3-A3
> Average throughput = 9889 messages per second
>
>
> Then finally I removed that patch so there were no interactivity patches:
> Test3-mm3-ni
> Average throughput = 11052 messages per second
Well that was quick, thanks.
Surely the only reason we see more idle time in this sort of workload is
because of runqueue imbalance: some CPUs are idle while other CPUs have
more than one runnable process. That sounds like a bug more than a
tuning/balancing thing: having no runnable tasks is a sort of binary
do-something-right-now case.
We should be going across and pullng a task off another CPU synchronously
as soon as a runqueue is seen to be empty. The code tries to do that so
hrm.
Ingo just sent the below patch which is related, but doesn't look like it
will fix it. I'll include this in test4-mm1, RSN.
From: Ingo Molnar <mingo@elte.hu>
the attached patch fixes the SMP balancing problem reported by David
Mosberger. (the 'yield-ing threads do not get spread out properly' bug).
it turns out that we never really spread out tasks in the busy-rebalance
case - contrary to my intention. The most likely incarnation of this
balancing bug is via yield() - but in theory pipe users can be affected
too.
the patch balances more agressively with a slow frequency, on SMP (or
within the same node on NUMA - not between nodes on NUMA).
kernel/sched.c | 3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
diff -puN kernel/sched.c~sched-balance-fix-2.6.0-test3-mm3-A0 kernel/sched.c
--- 25/kernel/sched.c~sched-balance-fix-2.6.0-test3-mm3-A0 2003-08-23 13:57:06.000000000 -0700
+++ 25-akpm/kernel/sched.c 2003-08-23 13:57:06.000000000 -0700
@@ -1144,7 +1144,6 @@ static void rebalance_tick(runqueue_t *t
load_balance(this_rq, idle, cpu_to_node_mask(this_cpu));
spin_unlock(&this_rq->lock);
}
- return;
}
#ifdef CONFIG_NUMA
if (!(j % BUSY_NODE_REBALANCE_TICK))
@@ -1152,7 +1151,7 @@ static void rebalance_tick(runqueue_t *t
#endif
if (!(j % BUSY_REBALANCE_TICK)) {
spin_lock(&this_rq->lock);
- load_balance(this_rq, idle, cpu_to_node_mask(this_cpu));
+ load_balance(this_rq, 0, cpu_to_node_mask(this_cpu));
spin_unlock(&this_rq->lock);
}
}
_
next prev parent reply other threads:[~2003-08-23 21:47 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-23 5:55 [PATCH]O18.1int Con Kolivas
2003-08-23 9:08 ` [PATCH]O18.1int Thomas Schlichter
2003-08-23 9:18 ` [PATCH]O18.1int Nick Piggin
2003-08-23 12:22 ` [PATCH]O18.1int Con Kolivas
2003-08-23 12:21 ` [PATCH]O18.1int Con Kolivas
2003-08-23 9:32 ` [PATCH]O18.1int Andrew Morton
2003-08-23 9:49 ` [PATCH]O18.1int Nick Piggin
2003-08-23 16:58 ` [PATCH]O18.1int Con Kolivas
2003-08-23 21:49 ` Andrew Morton [this message]
2003-08-24 2:46 ` [PATCH]O18.1int Con Kolivas
2003-08-23 13:29 ` [PATCH]O18.1int Con Kolivas
2003-08-25 9:24 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 9:42 ` [PATCH]O18.1int Alex Riesen
2003-08-25 10:16 ` [PATCH]O18.1int Con Kolivas
2003-08-25 10:21 ` [PATCH]O18.1int Alex Riesen
2003-08-25 21:02 ` [PATCH]O18.1int Alex Riesen
2003-08-25 22:48 ` [PATCH]O18.1int Con Kolivas
2003-08-25 23:00 ` [PATCH]O18.1int Alex Riesen
2003-08-26 22:03 ` [PATCH]O18.1int Alex Riesen
2003-08-25 10:34 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 10:50 ` [PATCH]O18.1int Con Kolivas
2003-08-25 11:15 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 11:37 ` [PATCH]O18.1int Con Kolivas
2003-08-25 11:58 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 12:28 ` [PATCH]O18.1int Con Kolivas
2003-08-25 12:49 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 13:32 ` [PATCH]O18.1int Con Kolivas
2003-08-25 10:17 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 10:34 ` [PATCH]O18.1int Alex Riesen
2003-08-25 11:23 ` [PATCH]O18.1int Måns Rullgård
2003-08-25 10:48 ` [PATCH]O18.1int Con Kolivas
[not found] ` <3F49E482.7030902@cyberone.com.au>
[not found] ` <20030825102933.GA14552@Synopsys.COM>
2003-08-26 22:20 ` [PATCH]O18.1int Alex Riesen
2003-08-27 2:26 ` [PATCH]O18.1int Nick Piggin
2003-08-23 22:03 [PATCH]O18.1int Voluspa
2003-08-24 4:04 ` [PATCH]O18.1int Con Kolivas
2003-08-28 12:23 [PATCH]O18.1int Guillaume Chazarain
2003-08-28 13:43 [PATCH]O18.1int Guillaume Chazarain
2003-08-28 13:58 ` [PATCH]O18.1int Nick Piggin
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=20030823144907.6bcce289.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mingo@elte.hu \
--cc=piggin@cyberone.com.au \
/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;
as well as URLs for NNTP newsgroup(s).