From: Peter Williams <pwil3058@bigpond.net.au>
To: Andrew Morton <akpm@osdl.org>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
efault@gmx.de, nickpiggin@yahoo.com.au, mingo@elte.hu,
kernel@kolivas.org, kenneth.w.chen@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [patch] smpnice: don't consider sched groups which are lightly loaded for balancing
Date: Fri, 21 Apr 2006 10:28:02 +1000 [thread overview]
Message-ID: <44482712.5030401@bigpond.net.au> (raw)
In-Reply-To: <20060420164936.5988460d.akpm@osdl.org>
Andrew Morton wrote:
> "Siddha, Suresh B" <suresh.b.siddha@intel.com> wrote:
>> updated patch appended. thanks.
>
> Where are we up to with smpnice now? Are there still any known
> regressions/problems/bugs/etc?
One more change to move_tasks() is required to address an issue raised
by Suresh w.r.t. the possibility unnecessary movement of the highest
priority task from the busiest queue (possible because of the
active/expired array mechanism). I hope to forward a patch for this
later today.
After that the only thing I would like to do at this stage is modify
try_to_wake_up() so that it tries harder to distribute high priority
tasks across the CPUs. I wouldn't classify this as absolutely necessary
as it's really just a measure that attempts to reduce latency for high
priority tasks as it should get them onto a CPU more quickly than just
sticking them anywhere and waiting for load balancing to kick in if
they've been put on a CPU with a higher priority task already running.
Also it's only really necessary when there a lot of high priority tasks
running. So this isn't urgent and probably needs to be coordinated with
Ingo's RT load balancing stuff anyway.
> Has sufficient testing been done for us to
> know this?
I run smpnice kernels on all of my SMP machines all of the time. But I
don't have anything with more than 2 CPUs so I've been relying on their
presence in -mm to get wider testing on larger machines.
I think that once this patch and the move_tasks() one that I'll forward
later today are incorporated we should have something that (although not
perfect) works pretty well. Neither of these changes should cause a
behavioural change in the case where all tasks are nice==0.
As load balancing is inherently probabilistic I don't think that we
should hold out for "perfect".
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
next prev parent reply other threads:[~2006-04-21 0:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-28 6:00 [PATCH] sched: smpnice work around for active_load_balance() Peter Williams
2006-03-28 19:25 ` Siddha, Suresh B
2006-03-28 22:44 ` Peter Williams
2006-03-29 2:14 ` Peter Williams
2006-03-29 2:52 ` Siddha, Suresh B
2006-03-29 3:42 ` Peter Williams
2006-03-29 22:52 ` Siddha, Suresh B
2006-03-29 23:40 ` Peter Williams
2006-03-30 0:50 ` Siddha, Suresh B
2006-03-30 1:14 ` Peter Williams
2006-04-02 4:48 ` smpnice loadbalancing with high priority tasks Siddha, Suresh B
2006-04-02 7:08 ` Peter Williams
2006-04-04 0:24 ` Siddha, Suresh B
2006-04-04 1:22 ` Peter Williams
2006-04-04 1:34 ` Peter Williams
2006-04-04 2:11 ` Siddha, Suresh B
2006-04-04 3:24 ` Peter Williams
2006-04-04 4:34 ` Peter Williams
2006-04-06 2:14 ` Peter Williams
2006-04-20 1:24 ` [patch] smpnice: don't consider sched groups which are lightly loaded for balancing Siddha, Suresh B
2006-04-20 5:19 ` Peter Williams
2006-04-20 16:54 ` Siddha, Suresh B
2006-04-20 23:11 ` Peter Williams
2006-04-20 23:49 ` Andrew Morton
2006-04-21 0:25 ` Siddha, Suresh B
2006-04-21 0:28 ` Peter Williams [this message]
2006-04-21 1:25 ` Andrew Morton
2006-04-20 17:04 ` Siddha, Suresh B
2006-04-21 0:00 ` Peter Williams
2006-04-03 1:04 ` [PATCH] sched: smpnice work around for active_load_balance() Peter Williams
2006-04-03 16:57 ` Siddha, Suresh B
2006-04-03 23:11 ` Peter Williams
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=44482712.5030401@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=akpm@osdl.org \
--cc=efault@gmx.de \
--cc=kenneth.w.chen@intel.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=suresh.b.siddha@intel.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.