lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rfc][patch] sched: remove smpnice
Peter Williams wrote:
> Andrew Morton wrote:
>
>> "Siddha, Suresh B" <suresh.b.siddha@intel.com> wrote:
>>
>>> On Tue, Feb 07, 2006 at 03:36:17PM -0800, Andrew Morton wrote:
>>>
>>>> Suresh, Martin, Ingo, Nick and Con: please drop everything,
>>>> triple-check
>>>> and test this:
>>>>
>>>> From: Peter Williams <pwil3058@bigpond.net.au>
>>>>
>>>> This is a modified version of Con Kolivas's patch to add "nice"
>>>> support to
>>>> load balancing across physical CPUs on SMP systems.
>>>
>>>
>>> I have couple of issues with this patch.
>>>
>>> a) on a lightly loaded system, this will result in higher priority
>>> job hopping around from one processor to another processor.. This is
>>> because of the code in find_busiest_group() which assumes that
>>> SCHED_LOAD_SCALE represents a unit process load and with nice_to_bias
>>> calculations this is no longer true(in the presence of non nice-0 tasks)
>>>
>>> My testing showed that 178.galgel in SPECfp2000 is down by ~10% when
>>> run with nice -20 on a 4P(8-way with HT) system compared to a nice-0
>>> run.
>
>
> This is a bit of a surprise. Surely, even with this mod, a task
> shouldn't be moved if it's the only runnable one on its CPU. If it
> isn't the only runnable one on its CPU, it's not actually on the CPU and
> it's not cache hot then moving it to another (presumably) idle CPU
> should be a gain?
>
> Presumably the delay waiting for the current task to exit the CPU is
> less than the time taken to move the task to the new CPU? I'd guess
> that this means that the task about to be moved is either: a) higher
> priority than the current task on the CPU and is waiting for it to be
> preempted off or b) it's equal priority (or at least next one due to be
> scheduled) to the current task, waiting for the current task to
> surrender the CPU and that surrender is going to happen pretty quickly
> due to the current task's natural behaviour?

After a little lie down :-), I now think that this problem has been
misdiagnosed and the actual problem is that movement of high priority
tasks on lightly loaded systems is supressed by this patch rather than
it causing such tasks to hop from CPU to CPU.

The reason that I think this is that the implementation of biased_load()
makes it a likely outcome. As a shortcut to converting weighted load to
biased load it assumes the the average weighted load per runnable task
is 1 (or, equivalently, that the average biased prio per runnable is
NICE_TO_BIAS_PRIO(p)) and this means that if there's only one task to
move and its nice value is less than zero (i.e. it's high priority) then
the biased load to be moved that is calculated will be smaller than that
task's bias_prio causing it to NOT be moved by move_tasks().

Do you have any direct evidence to support your "hopping" hypothesis or
is my hypothesis equally likely?

If my hypothesis holds there is a relatively simple fix that would
involve modifying biased_load() to take into account rq->prio_bias and
rq->nr_running during its calculations. Basically, in that function,
(wload * NICE_TO_BIAS_PRIO(0)) would be replaced by (wload *
rq->prio_bias / rq->nr_running) which would, in turn, create a
requirement for rq to be passed in as an argument.

If there is direct evidence of hopping then, because of my hypothesis
above, I would shift the suspicion from find_busiest_group() to
try_to_wake_up().

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-11 04:38    [W:0.464 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site