[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfTPtDqKqoLg9OOYMy5bVVnQKGNb3Z9hL6tWaxqKzv2+NdFXw@mail.gmail.com>
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
Powered by blists - more mailing lists