From: Nick Piggin <piggin@cyberone.com.au>
To: habanero@us.ibm.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Minor scheduler fix to get rid of skipping in xmms
Date: Thu, 11 Sep 2003 21:04:45 +1000 [thread overview]
Message-ID: <3F6056CD.6040402@cyberone.com.au> (raw)
In-Reply-To: <200309102155.16407.habanero@us.ibm.com>
Andrew Theurer wrote:
>Robert Love <rml@tech9.net> wrote:
>
>>> There are a _lot_ of scheduler changes in 2.6-mm, and who knows which
>>> ones are an improvement, a detriment, and a noop?
>>>
>
>>We know that sched-2.6.0-test2-mm2-A3.patch caused the regression, and
>>we now that sched-CAN_MIGRATE_TASK-fix.patch mostly fixed it up.
>>
>
>>What we don't know is whether the thing which
>>sched-CAN_MIGRATE_TASK-fix.patch
>>fixed was the thing which sched-2.6.0-test2-mm2-A3.patch broke.
>>
>
>Sorry for jumping into this late. I didn't even know the can_migrate patch
>was being discussed, let alone in -mm :). And to be fair, this really is
>Ingo's aggressive idle steal patch.
>
>Anyway, these patches are somewhat related. It would seem that A3's
>shortening the tasks' run time would not only slow performance beacuse of
>cache thrash, but could possibly break CAN_MIGRATE's cache warmth check,
>right? That in turn would stop load balancing from working well, leading to
>more idle time, which the CAN_MIGRATE patch sort of bypassed for idle cpus.
>
Yeah thats probably right. Good thinking.
>
>I see Nick's balance patch as somewhat harmless, at least combined with A3
>patch. However, one concern is that the "ping-pong" steal interval is not
>really 200ms, but 200ms/(nr_cpus-1), which without A3, could show up as a
>problem, especially on an 8 way box. In addition, I do think there's a
>problem with num tasks we steal. It should not be imbalance/2, it should be:
>max_load - (node_nr_running / num_cpus_node). If we steal any more than
>this, which is quite possible with imbalance/2, then it's likely this_cpu now
>has too many tasks, and some other cpu will steal again. Using *imbalance/2
>works fine on 2-way smp, but I'm pretty sure we "over steal" tasks on 4 way
>and up. Anyway, I'm getting off topic here...
>
IIRC max_load is supposed to be the number of tasks on the runqueue
being stolen from, isn't it?
next prev parent reply other threads:[~2003-09-11 11:05 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-11 2:55 [PATCH] Minor scheduler fix to get rid of skipping in xmms Andrew Theurer
2003-09-11 11:04 ` Nick Piggin [this message]
2003-09-11 13:05 ` Andrew Theurer
2003-09-11 13:53 ` Nick Piggin
2003-09-11 14:37 ` Andrew Theurer
-- strict thread matches above, loose matches on Subject: below --
2003-09-11 23:32 Craig Thomas
[not found] <tCPY.4xU.1@gated-at.bofh.it>
[not found] ` <tDsR.5tY.31@gated-at.bofh.it>
[not found] ` <tZ0f.49P.5@gated-at.bofh.it>
[not found] ` <tZjz.4Bn.7@gated-at.bofh.it>
2003-09-09 23:24 ` David Mosberger-Tang
2003-09-08 22:27 Steven Pratt
2003-09-08 22:56 ` Andrew Morton
2003-09-08 23:22 ` William Lee Irwin III
2003-09-09 2:10 ` Con Kolivas
2003-09-09 2:16 ` Con Kolivas
2003-09-09 2:31 ` Con Kolivas
2003-09-09 2:33 ` Andrew Morton
2003-09-09 4:14 ` Nick Piggin
2003-09-09 6:49 ` Con Kolivas
2003-09-09 23:53 ` Cliff White
2003-09-10 2:12 ` Nick Piggin
2003-09-10 19:05 ` Steven Pratt
2003-09-10 20:23 ` Dave Hansen
[not found] ` <3F5FE385.10204@cyberone.com.au>
[not found] ` <3F607E62.3010903@austin.ibm.com>
[not found] ` <3F60873B.4000005@cyberone.com.au>
2003-09-11 22:57 ` Steven Pratt
2003-09-11 0:14 ` Cliff White
2003-09-09 22:06 ` Steven Pratt
2003-09-09 22:12 ` Andrew Morton
2003-09-10 13:59 ` Steven Pratt
2003-09-10 18:51 ` Steven Pratt
2003-09-06 15:58 John Yau
2003-09-06 16:57 ` Michael Buesch
2003-09-06 9:46 John Yau
2003-09-06 10:03 ` Michael Buesch
2003-09-06 17:01 ` Robert Love
2003-09-06 17:59 ` John Yau
2003-09-06 18:17 ` John Yau
2003-09-06 19:42 ` Rahul Karnik
2003-09-06 20:04 ` Robert Love
2003-09-06 22:41 ` John Yau
2003-09-07 2:40 ` Martin J. Bligh
2003-09-07 5:13 ` Nick Piggin
2003-09-07 7:48 ` Johnny Yau
2003-09-07 8:10 ` Nick Piggin
2003-09-07 8:35 ` John Yau
2003-09-07 9:26 ` Nick Piggin
2003-09-07 17:30 ` John Yau
2003-09-07 17:36 ` Nick Piggin
2003-09-08 0:22 ` Con Kolivas
2003-09-08 0:27 ` David Lang
2003-09-08 0:47 ` Con Kolivas
2003-09-07 5:08 ` Nick Piggin
2003-09-07 6:18 ` Andrew Morton
2003-09-07 6:29 ` Nick Piggin
2003-09-07 6:45 ` Andrew Morton
2003-09-07 6:59 ` Nick Piggin
2003-09-07 7:02 ` Nick Piggin
2003-09-07 14:32 ` Martin J. Bligh
2003-09-07 17:02 ` Robert Love
2003-09-07 17:34 ` Andrew Morton
2003-09-07 18:12 ` Nick Piggin
2003-09-07 18:13 ` 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=3F6056CD.6040402@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=habanero@us.ibm.com \
--cc=linux-kernel@vger.kernel.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 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.