From: Alex Shi <alex.shi@linaro.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
"fweisbec@gmail.com" <fweisbec@gmail.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"fenghua.yu@intel.com" <fenghua.yu@intel.com>,
"james.hogan@imgtec.com" <james.hogan@imgtec.com>,
"jason.low2@hp.com" <jason.low2@hp.com>,
"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"arjan@linux.intel.com" <arjan@linux.intel.com>,
"pjt@google.com" <pjt@google.com>,
"fengguang.wu@intel.com" <fengguang.wu@intel.com>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
"wangyun@linux.vnet.ibm.com" <wangyun@linux.vnet.ibm.com>
Subject: Re: [PATCH v2 0/11] remove cpu_load in rq
Date: Wed, 19 Feb 2014 18:23:34 +0800 [thread overview]
Message-ID: <53048626.2000803@linaro.org> (raw)
In-Reply-To: <CAKfTPtDtv=hFtprNpAfRVMEAvWZn-55u8fcHTdJT6xT92Qdt-g@mail.gmail.com>
>> Removing cpu_load completely certainly makes things simpler, my worry is
>> just how much was lost by doing it. I agree that cpu_load needs a
>> cleanup, but I can't convince myself that just removing it completely
>> and not having any longer term view of cpu load anymore is without any
>> negative side-effects.
>
> Hi Alex,
>
> Have you followed this thread about load_idx and the interest of using
> them to use different average period ?
> https://lkml.org/lkml/2014/1/6/499
Yes, I hoped to use blocked load before. But I still can not figure out
the correct usage of it.
Or maybe we need more quick decay for blocked load?
Or, maybe clean cpu_load is helpful to make room to reconsider this.
>
> Vincent
>
>>
>> {source, target}_load() are now instantaneous views of the cpu load,
>> which means that they may change very frequently. That could potentially
>> lead to more task migrations at all levels in the domain hierarchy as we
>> no longer have the more conservative cpu_load[] indexes that were used
>> at NUMA level.
>>
>> Maybe some of the NUMA experts have an opinion about this?
>>
>> In the discussions around V1 I think blocked load came up again as a
>> potential replacement for the current cpu_load array. There are some
>> issues that need to be solved around blocked_load first though.
>>
>> Morten
--
Thanks
Alex
prev parent reply other threads:[~2014-02-19 10:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 1:55 [PATCH v2 0/11] remove cpu_load in rq Alex Shi
2014-02-17 1:55 ` [PATCH v2 01/11] sched: shortcut to remove load_idx Alex Shi
2014-02-17 1:55 ` [PATCH v2 02/11] sched: remove rq->cpu_load[load_idx] array Alex Shi
2014-02-17 1:55 ` [PATCH v2 03/11] sched: clean up cpu_load update Alex Shi
2014-02-17 1:55 ` [PATCH v2 04/11] sched: unify imbalance bias for target group Alex Shi
2014-02-17 1:55 ` [PATCH v2 05/11] sched: rewrite update_cpu_load_nohz Alex Shi
2014-02-17 1:55 ` [PATCH v2 06/11] sched: clean up source_load/target_load Alex Shi
2014-02-17 1:55 ` [PATCH v2 07/11] sched: clean up weighted_cpuload Alex Shi
2014-02-17 1:55 ` [PATCH v2 08/11] sched: remove weighted_load() Alex Shi
2014-02-17 1:55 ` [PATCH v2 09/11] sched: remove rq->cpu_load and rq->nr_load_updates Alex Shi
2014-02-17 1:55 ` [PATCH v2 10/11] sched: rename update_*_cpu_load Alex Shi
2014-02-17 1:55 ` [PATCH v2 11/11] sched: clean up task_hot function Alex Shi
2014-02-18 2:37 ` [PATCH v2 0/11] remove cpu_load in rq Alex Shi
2014-02-18 4:52 ` Michael wang
2014-02-18 6:03 ` Alex Shi
2014-02-18 6:17 ` Michael wang
[not found] ` <20140218120522.GG19029@e103034-lin>
2014-02-18 12:28 ` Vincent Guittot
2014-02-19 10:23 ` 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=53048626.2000803@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=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.