[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4624D40E.10500@bigpond.net.au>
Date: Wed, 18 Apr 2007 00:05:02 +1000
From: Peter Williams <pwil3058@...pond.net.au>
To: Ingo Molnar <mingo@...e.hu>
CC: William Lee Irwin III <wli@...omorphy.com>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Con Kolivas <kernel@...ivas.org>,
Nick Piggin <npiggin@...e.de>, Mike Galbraith <efault@....de>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>, caglar@...dus.org.tr,
Willy Tarreau <w@....eu>,
Gene Heskett <gene.heskett@...il.com>,
Dmitry Adamushko <dmitry.adamushko@...il.com>
Subject: Re: [patch] CFS (Completely Fair Scheduler), v2
Ingo Molnar wrote:
> * William Lee Irwin III <wli@...omorphy.com> wrote:
>
>> On Tue, Apr 17, 2007 at 04:46:57PM +1000, Peter Williams wrote:
>>
>>> Have you considered using rq->raw_weighted_load instead of
>>> rq->nr_running in calculating fair_clock? This would take the nice
>>> value (or RT priority) of the other tasks into account when
>>> determining what's fair.
>> I suspect you mean
>> (curr->load_weight*delta_exec)/rq->raw_weighted_load in update_curr().
>
> good idea, i'll try that.
In the longer term, I'd suggest modifying this idea to use the maximum
of rq->raw_weighted_load and a running average of rq->raw_weighted_load
much the same as was done within the load balancer code. This will tend
to make scheduling "smoother". To try the idea out you could (on an SMP
system) use one of the rq->cpu_load[] metrics as the running average.
Peter
--
Peter Williams pwil3058@...pond.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists