From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 00E34C388F9 for ; Wed, 21 Oct 2020 12:56:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB2E622249 for ; Wed, 21 Oct 2020 12:56:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2442719AbgJUM4J (ORCPT ); Wed, 21 Oct 2020 08:56:09 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:47797 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2442709AbgJUM4J (ORCPT ); Wed, 21 Oct 2020 08:56:09 -0400 X-IronPort-AV: E=Sophos;i="5.77,401,1596492000"; d="scan'208";a="473682632" Received: from 173.121.68.85.rev.sfr.net (HELO hadrien) ([85.68.121.173]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2020 14:56:06 +0200 Date: Wed, 21 Oct 2020 14:56:06 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Mel Gorman cc: Vincent Guittot , Julia Lawall , Ingo Molnar , kernel-janitors@vger.kernel.org, Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org, Valentin Schneider , Gilles.Muller@inria.fr Subject: Re: [PATCH] sched/fair: check for idle core In-Reply-To: <20201021124700.GE32041@suse.de> Message-ID: References: <1603211879-1064-1-git-send-email-Julia.Lawall@inria.fr> <20201021112038.GC32041@suse.de> <20201021122532.GA30733@vingu-book> <20201021124700.GE32041@suse.de> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1257254928-1603284967=:8475" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1257254928-1603284967=:8475 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8BIT On Wed, 21 Oct 2020, Mel Gorman wrote: > On Wed, Oct 21, 2020 at 02:25:32PM +0200, Vincent Guittot wrote: > > > I see Vincent already agreed with the patch so I could be wrong. Vincent, > > > did I miss something stupid? > > > > This patch fixes the problem that we don't favor anymore the prev_cpu when it is idle since > > commit 11f10e5420f6ce because load is not null when cpu is idle whereas runnable_load was > > And this is important because this will then decide in which LLC we will looks for a cpu > > > > Ok, that is understandable but I'm still concerned that the fix simply > trades one problem for another by leaving related tasks remote to each > other and increasing cache misses and remote data accesses. > > wake_affine_weight is a giant pain because really we don't care about the > load on the waker CPU or its available, we care about whether it has idle > siblings that can be found quickly. As tempting as ripping it out is, > it never happened because sometimes it makes the right decision. My goal was to restore the previous behavior, when runnable load was used. The patch removing the use of runnable load (11f10e5420f6) presented it basically as that load balancing was using it, so wakeup should use it too, and any way it didn't matter because idle CPUS were checked for anyway. Is your point of view that the proposed change is overkill? Or is it that the original behavior was not desirable? thanks, julia --8323329-1257254928-1603284967=:8475-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julia Lawall Date: Wed, 21 Oct 2020 12:56:06 +0000 Subject: Re: [PATCH] sched/fair: check for idle core Message-Id: MIME-Version: 1 Content-Type: multipart/mixed; boundary="8323329-1257254928-1603284967=:8475" List-Id: References: <1603211879-1064-1-git-send-email-Julia.Lawall@inria.fr> <20201021112038.GC32041@suse.de> <20201021122532.GA30733@vingu-book> <20201021124700.GE32041@suse.de> In-Reply-To: <20201021124700.GE32041@suse.de> To: Mel Gorman Cc: Vincent Guittot , Julia Lawall , Ingo Molnar , kernel-janitors@vger.kernel.org, Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org, Valentin Schneider , Gilles.Muller@inria.fr This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1257254928-1603284967=:8475 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Wed, 21 Oct 2020, Mel Gorman wrote: > On Wed, Oct 21, 2020 at 02:25:32PM +0200, Vincent Guittot wrote: > > > I see Vincent already agreed with the patch so I could be wrong. Vin= cent, > > > did I miss something stupid? > > > > This patch fixes the problem that we don't favor anymore the prev_cpu w= hen it is idle since > > commit 11f10e5420f6ce because load is not null when cpu is idle whereas= runnable_load was > > And this is important because this will=A0then decide in which LLC we w= ill looks for a cpu > > > > Ok, that is understandable but I'm still concerned that the fix simply > trades one problem for another by leaving related tasks remote to each > other and increasing cache misses and remote data accesses. > > wake_affine_weight is a giant pain because really we don't care about the > load on the waker CPU or its available, we care about whether it has idle > siblings that can be found quickly. As tempting as ripping it out is, > it never happened because sometimes it makes the right decision. My goal was to restore the previous behavior, when runnable load was used. The patch removing the use of runnable load (11f10e5420f6) presented it basically as that load balancing was using it, so wakeup should use it too, and any way it didn't matter because idle CPUS were checked for anyway. Is your point of view that the proposed change is overkill? Or is it that the original behavior was not desirable? thanks, julia --8323329-1257254928-1603284967=:8475--