linux-kernel - Re: [PATCH] sched/fair: Rearrange select_task_rq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180425105557.GA10471@e108498-lin.cambridge.arm.com>
Date:   Wed, 25 Apr 2018 11:55:57 +0100
From:   Quentin Perret <quentin.perret@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: Rearrange select_task_rq_fair() to optimize
 it

On Wednesday 25 Apr 2018 at 15:43:13 (+0530), Viresh Kumar wrote:
> On 25-04-18, 10:39, Quentin Perret wrote:
> > On Wednesday 25 Apr 2018 at 14:33:27 (+0530), Viresh Kumar wrote:
> > > On 25-04-18, 09:13, Quentin Perret wrote:
> > > > While you're at it, you could probably remove the one in wake_cap() ? I
> > > > think having just one in select_task_rq_fair() should be enough.
> > > 
> > > Just make it clear, you are asking me to remove sync_entity_load_avg()
> > > in wake_cap() ? But aren't we required to do that, as in the very next
> > > line we call task_util(p) ?
> > 
> > Right, we do need to call sync_entity_load_avg() at some point before
> > calling task_util(), but we don't need to re-call it in strf()
> > after in this case. So my point was just that if you want to re-work
> > the wake-up path and make sure we don't call sync_entity_load_avg()
> > if not needed then this might need fixing as well ... Or maybe we don't
> > care since re-calling sync_entity_load_avg() should be really cheap ...
> 
> These are in two very different paths and I am not sure of a clean way
> to avoid calling sync_entity_load_avg() again. Maybe will leave it as
> is for now.

Fair enough, I don't really like this double call but, looking into more
details, I'm not sure how to avoid it cleanly either ...