[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ec72421264eadcfde3491076ed4e7b60d08ad44a.camel@surriel.com>
Date: Wed, 19 Jun 2019 11:55:10 -0400
From: Rik van Riel <riel@...riel.com>
To: Dietmar Eggemann <dietmar.eggemann@....com>, peterz@...radead.org
Cc: mingo@...hat.com, linux-kernel@...r.kernel.org, kernel-team@...com,
morten.rasmussen@....com, tglx@...utronix.de,
dietmar.eggeman@....com, mgorman@...hsingularity.com,
vincent.guittot@...aro.org
Subject: Re: [PATCH 1/8] sched: introduce task_se_h_load helper
On Wed, 2019-06-19 at 17:18 +0200, Dietmar Eggemann wrote:
> On 6/19/19 3:57 PM, Rik van Riel wrote:
>
> > That would work, but task_h_load then dereferences
> > task->se to get the se->avg.load_avg value.
> >
> > Going back to task from the se, only to then get the
> > se from the task seems a little unnecessary :)
> >
> > Can you explain why you think task_h_load(task_of(se))
> > would be better? I think I may be overlooking something.
>
> Ah, OK, I just wanted to avoid having task_se_h_load() and
> task_h_load()
> at the same time. You could replace the remaining calls to
> task_h_load(p) with task_se_h_load(&p->se) in this case.
>
> - task_load = task_h_load(p);
> + task_load = task_se_h_load(&p->se);
>
> Not that important though right now ...
That I can do.
I might as well do that while going through the
rest of the series to merge in the bug fix that
I have for the performance regression, and the
fixes for compilation with other config options.
Thank you for the suggestion.
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists