linux-kernel - Re: SD_LOAD

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]

Date:   Mon, 12 Oct 2020 13:09:19 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Julia Lawall <julia.lawall@...ia.fr>
Cc:     Valentin Schneider <valentin.schneider@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Gilles Muller <Gilles.Muller@...ia.fr>
Subject: Re: SD_LOAD_BALANCE

On Mon, 12 Oct 2020 at 12:34, Julia Lawall <julia.lawall@...ia.fr> wrote:
>
> > > Would it be useful to always check whether prev is idle, perhaps in
> > > wake_affine_idle or perhaps in select_idle_sibling?
> >
> > Yes, that would make sense to add a condition in  wake_affine_idle to
> > return prev if this cpu is not idle (or about to become idle)
>
> The case where this cpu is idle would be in the interrupt case.  If both
> prev cpu and this cpu are idle, is it more desirable to move the thread to
> this cpu or to leave it where it was?

I think that we should keep the current behavior regarding this cpu
and the shared cache case and add one more test before the last return
of the function.

right now, we select this_cpu:
-if this cpu is idle,  it shares cache with prev and previous is not idle.
-if it's a sync wake up because we expect the task to use local data
of the current running task on this cpu.

Then we add a new case to return prev cpu if it is idle which is your case


>
> julia