[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51876AFE.80906@linux.vnet.ibm.com>
Date: Mon, 06 May 2013 16:34:06 +0800
From: Michael Wang <wangyun@...ux.vnet.ibm.com>
To: Alex Shi <alex.shi@...el.com>
CC: pjt@...gle.com, mingo@...hat.com, peterz@...radead.org,
tglx@...utronix.de, akpm@...ux-foundation.org, bp@...en8.de,
namhyung@...nel.org, efault@....de, morten.rasmussen@....com,
vincent.guittot@...aro.org, preeti@...ux.vnet.ibm.com,
viresh.kumar@...aro.org, linux-kernel@...r.kernel.org,
mgorman@...e.de, riel@...hat.com
Subject: Re: [PATCH v5 7/7] sched: consider runnable load average in effective_load
On 05/06/2013 04:02 PM, Alex Shi wrote:
> On 05/06/2013 03:49 PM, Michael Wang wrote:
>> On 05/06/2013 01:39 PM, Alex Shi wrote:
>> [snip]
>>
>> Rough test done:
>>
>>>
>>> 1, change back the tg_weight in calc_tg_weight() to use tg_load_contrib not direct load.
>>
>> This way stop the regression of patch 7.
>>
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 6f4f14b..c770f8d 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -1037,8 +1037,8 @@ static inline long calc_tg_weight(struct task_group *tg, struct cfs_rq *cfs_rq)
>>> * update_cfs_rq_load_contribution().
>>> */
>>> tg_weight = atomic64_read(&tg->load_avg);
>>> - tg_weight -= cfs_rq->tg_load_contrib;
>>> - tg_weight += cfs_rq->load.weight;
>>> + //tg_weight -= cfs_rq->tg_load_contrib;
>>> + //tg_weight += cfs_rq->load.weight;
>>>
>>> return tg_weight;
>>> }
>>>
>>> 2, another try is follow the current calc_tg_weight, so remove the follow change.
>>
>> This way show even better results than only patch 1~6.
>
> how much better to the first change?
Nevermind, it's just a rough test, consider them as same...
>>
>> But the way Preeti suggested doesn't works...
>
> What's the Preeti suggestion? :)
Paste at last.
>>
>> May be we should record some explanation about this change here, do we?
>
> I don't know why we need this, PJT, would you like to tell us why the
> calc_tg_weight use cfs_rq->load.weight not cfs_rq->tg_load_contrib?
The comment said this is more accurate, but that was for the world
without decay load I suppose...
But if it using 'cfs_rq->load.weight', which means denominator M contain
that factor, than numerator w has to contain it also...
Regards,
Michael Wang
>
>
>>
>> Regards,
>> Michael Wang
>>
sched: Modify effective_load() to use runnable load average
From: Preeti U Murthy <preeti@...ux.vnet.ibm.com>
The runqueue weight distribution should update the runnable load average of
the cfs_rq on which the task will be woken up.
However since the computation of se->load.weight takes into consideration
the runnable load average in update_cfs_shares(),no need to modify this in
effective_load().
---
kernel/sched/fair.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 790e23d..5489022 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3045,7 +3045,7 @@ static long effective_load(struct task_group *tg,
int cpu, long wl, long wg)
/*
* w = rw_i + @wl
*/
- w = se->my_q->load.weight + wl;
+ w = se->my_q->runnable_load_avg + wl;
/*
* wl = S * s'_i; see (2)
@@ -3066,6 +3066,9 @@ static long effective_load(struct task_group *tg,
int cpu, long wl, long wg)
/*
* wl = dw_i = S * (s'_i - s_i); see (3)
*/
+ /* Do not modify the below as it already contains runnable
+ * load average in its computation
+ */
wl -= se->load.weight;
/*
@@ -3112,14 +3115,14 @@ static int wake_affine(struct sched_domain *sd,
struct task_struct *p, int sync)
*/
if (sync) {
tg = task_group(current);
- weight = current->se.load.weight;
+ weight = current->se.avg.load_avg_contrib;
this_load += effective_load(tg, this_cpu, -weight, -weight);
load += effective_load(tg, prev_cpu, 0, -weight);
}
tg = task_group(p);
- weight = p->se.load.weight;
+ weight = p->se.avg.load_avg_contrib;
/*
* In low-load situations, where prev_cpu is idle and this_cpu is idle
Regards
Preeti U Murthy
--
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