From: Alex Shi <alex.shi@linaro.org>
To: mingo@redhat.com, peterz@infradead.org, morten.rasmussen@arm.com
Cc: vincent.guittot@linaro.org, daniel.lezcano@linaro.org,
fweisbec@gmail.com, linux@arm.linux.org.uk, tony.luck@intel.com,
fenghua.yu@intel.com, james.hogan@imgtec.com,
alex.shi@linaro.org, jason.low2@hp.com, viresh.kumar@linaro.org,
hanjun.guo@linaro.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de, akpm@linux-foundation.org,
arjan@linux.intel.com, pjt@google.com, fengguang.wu@intel.com,
linaro-kernel@lists.linaro.org, wangyun@linux.vnet.ibm.com,
mgorman@suse.de
Subject: Re: [ PATCH 0/8] sched: remove cpu_load array
Date: Tue, 18 Mar 2014 10:17:40 +0800 [thread overview]
Message-ID: <5327ACC4.7000907@linaro.org> (raw)
In-Reply-To: <53266AFE.7020008@linaro.org>
On 03/17/2014 11:24 AM, Alex Shi wrote:
> On 03/13/2014 01:57 PM, Alex Shi wrote:
>> In the cpu_load decay usage, we mixed the long term, short term load with
>> balance bias, randomly pick a big/small value from them according to balance
>> destination or source. This mix is wrong, the balance bias should be based
>> on task moving cost between cpu groups, not on random history or instant load.
>> History load maybe diverage a lot from real load, that lead to incorrect bias.
>>
>> In fact, the cpu_load decays can be replaced by the sched_avg decay, that
>> also decays load on time. The balance bias part can fully use fixed bias --
>> imbalance_pct, which is already used in newly idle, wake, forkexec balancing
>> and numa balancing scenarios.
>>
>> Currently the only working idx is busy_idx and idle_idx.
>> As to busy_idx:
>> We mix history load decay and bias together. The ridiculous thing is, when
>> all cpu load are continuous stable, long/short term load is same. then we
>> lose the bias meaning, so any minimum imbalance may cause unnecessary task
>> moving. To prevent this funny thing happen, we have to reuse the
>> imbalance_pct again in find_busiest_group(). But that clearly causes over
>> bias in normal time. If there are some burst load in system, it is more worse.
>>
>
> Any comments?
IMHO, task moving resistance, bias, is only related with task migration
cost. no relationship with history load.
Another issue of history load mix with bias is that we want to care the
history load impact, but it is often ignored when instant load is fit
bias required more -- bigger in destination or smaller in source.
Any comments on this? :)
>
>> As to idle_idx:
>> Though I have some concern of usage correction,
>> https://lkml.org/lkml/2014/3/12/247, but since we are working on cpu
>> idle migration into scheduler. The problem will be reconsidered. We don't
>> need to care it now.
>>
>> This patch removed the cpu_load idx decay, since it can be replaced by
>> sched_avg feature. and left the imbalance_pct bias untouched, since only
>> idle_idx missed it, but it is fine. and will be reconsidered soon.
>>
>>
>> V5,
>> 1, remove unify bias patch and biased_load function. Thanks for PeterZ's
>> comments!
>> 2, remove get_sd_load_idx() in the 1st patch as SrikarD's suggestion.
>> 3, remove LB_BIAS feature, it is not needed now.
>
>
--
Thanks
Alex
prev parent reply other threads:[~2014-03-18 2:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-13 5:57 [ PATCH 0/8] sched: remove cpu_load array Alex Shi
2014-03-13 5:57 ` [PATCH 1/8] sched: shortcut to remove load_idx Alex Shi
2014-03-13 5:57 ` [PATCH 2/8] sched: remove rq->cpu_load[load_idx] array Alex Shi
2014-03-13 5:57 ` [PATCH 3/8] sched: remove source_load and target_load Alex Shi
2014-03-13 5:57 ` [PATCH 4/8] sched: remove LB_BIAS Alex Shi
2014-03-13 5:57 ` [PATCH 5/8] sched: clean up cpu_load update Alex Shi
2014-03-13 5:57 ` [PATCH 6/8] sched: rewrite update_cpu_load_nohz Alex Shi
2014-03-13 5:57 ` [PATCH 7/8] sched: remove rq->cpu_load and rq->nr_load_updates Alex Shi
2014-03-13 5:57 ` [PATCH 8/8] sched: rename update_*_cpu_load Alex Shi
2014-03-17 3:24 ` [ PATCH 0/8] sched: remove cpu_load array Alex Shi
2014-03-18 2:17 ` Alex Shi [this message]
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=5327ACC4.7000907@linaro.org \
--to=alex.shi@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=fengguang.wu@intel.com \
--cc=fenghua.yu@intel.com \
--cc=fweisbec@gmail.com \
--cc=hanjun.guo@linaro.org \
--cc=james.hogan@imgtec.com \
--cc=jason.low2@hp.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=wangyun@linux.vnet.ibm.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.