From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=ivDT=DT=vger.kernel.org=linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,
	USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 33D6FC433E7
	for <linux-kernel@archiver.kernel.org>; Mon, 12 Oct 2020 10:34:32 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id E726820790
	for <linux-kernel@archiver.kernel.org>; Mon, 12 Oct 2020 10:34:31 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2387555AbgJLKeb (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 12 Oct 2020 06:34:31 -0400
Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:2728 "EHLO
        mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S2387463AbgJLKea (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 12 Oct 2020 06:34:30 -0400
X-IronPort-AV: E=Sophos;i="5.77,366,1596492000"; 
   d="scan'208";a="472116579"
Received: from abo-173-121-68.mrs.modulonet.fr (HELO hadrien) ([85.68.121.173])
  by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2020 12:34:29 +0200
Date:   Mon, 12 Oct 2020 12:34:28 +0200 (CEST)
From:   Julia Lawall <julia.lawall@inria.fr>
X-X-Sender: jll@hadrien
To:     Vincent Guittot <vincent.guittot@linaro.org>
cc:     Valentin Schneider <valentin.schneider@arm.com>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Gilles Muller <Gilles.Muller@inria.fr>
Subject: Re: SD_LOAD_BALANCE
In-Reply-To: <CAKfTPtCPapkwS7B5X3XQsQFx7GXa-RSzRWO1e6n5JzLT7nTvrA@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2010121232410.2901@hadrien>
References: <alpine.DEB.2.22.394.2009031605190.2496@hadrien> <jhj7dtaokxe.mognet@arm.com> <alpine.DEB.2.22.394.2010101740290.2691@hadrien> <CAKfTPtCPapkwS7B5X3XQsQFx7GXa-RSzRWO1e6n5JzLT7nTvrA@mail.gmail.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > 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?

julia