lkml.org 
[lkml]   [2014]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RESEND PATCH V5 0/8] remove cpu_load idx

于 4/29/14, 23:04, Morten Rasmussen 写道:
> On Thu, Apr 24, 2014 at 05:20:29PM +0100, Peter Zijlstra wrote:
>> OK, this series is a lot saner, with the exception of 3/8 and
>> dependents.
>>
>> I do still worry a bit for loosing the longer term view for the big
>> domains though. Sadly I don't have any really big machines.
>>
>> I think the entire series is equivalent to setting LB_BIAS to false. So
>> I suppose we could do that for a while and if nobody reports horrible
>> things we could just do this.
>>
>> Anybody?
> I can't say what will happen on big machines, but I think the LB_BIAS
> test could be a way to see what happens. I'm not convinced that it won't
> lead to more task migrations since we will use the instantaneous cpu
> load (weighted_cpuload()) unfiltered.

Reject a simple and partly tested solution because of a untested guess?
Even the old double bias is better in few sceanrios, it doesn't mean it
is good
in theory.

I don't know the result on big machine too. but imbalance_pct of
sched_domain
is designed for balance bias on different domain level. We should tune
that instead
of bias on an random long term load.

Before runnable avg introduction, cpu_load idx make sense on history
load tracking.
With runnable avg, big instant load means tasks had been running for
long time. so
we already counted the task history.
As to the cpu history load, if it caused by task moving to other cpu, it
isn't right to
still count their load on old cpu.

> Morten

--
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: 2014-05-09 19:21    [W:0.152 / U:24.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site