Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp4804339rwb; Wed, 17 Aug 2022 06:27:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR7ZpvCpbzRkCmB1fekM6yJDNincbSBC0KDbksnm+xv8e2AhBFv7xnVDV6O5J9Wpnh4TClEi X-Received: by 2002:a17:907:28c8:b0:730:9ccc:331f with SMTP id en8-20020a17090728c800b007309ccc331fmr16299677ejc.608.1660742820274; Wed, 17 Aug 2022 06:27:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660742820; cv=none; d=google.com; s=arc-20160816; b=iGCqGmWlgaFriglJLarOit2yhN2v/qimBbh7f4/t7dg66GdCFLxhSBHcyTGbs2th15 Q8/4Pjb5FX8idBg+C8Su4XYd9PJ6iQ8nUDGmOVaREcVc+NmnTmecpnL+VxlcAb0nFo/B JN6JVTZsNDEqJbcv2lBhnt0RDq8Hkhprf9+Bm6Yi0gKn3T0/YpcJ0s8L5m4jhyemwqxE i+f8xke/0qS8do04HNSZgCvyLMj8Ge+Hp0yR1G3kjlIMSEOyP19MHuIgGKXH1QxOnjq5 lMbH8BLMaF4mAlI5bs8YOKrX1oXjnb462zwzUoBHNKpmdo37UirmIanHTryWhy2dqZMK kBLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1v5neMWckuuShK6mxvtzPriWYlr3sXVhkVDSWSsmeJw=; b=w0pdtqjcPGQROP9ev6MoPdlHp1xwx6K3c2knjpgmmnO8fkp6blrvjydzeX7obzO16u oB+HVNiIdSaQXzjVC1WgmctdnWY63omUAOJnwTm1DzCX2eAAmCM1xD+c/KIk5PDjm3R6 gapAGp/Jdd04gXXuYn6VUHg6BdIKmOrAmTH0HqcM9TIQA8ZttxruyY8uHYZ+Wl4IXv+g wYCXDMVJYk038hUA35rbi3/KuklRiQxqvDWhW7cUql6e4s1Y/dUd8l98KnLFCNwFuy4Z StcxEoIpGXsns0/nftsfckKCY24SaPZRdmNMJ/K7kR1m2eJw8Y9dDxMqEjT8VLjuGavy Sitg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LDBMjmyD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hg5-20020a1709072cc500b007386a8b4cfesi6184610ejc.827.2022.08.17.06.26.33; Wed, 17 Aug 2022 06:27:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LDBMjmyD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236486AbiHQNVM (ORCPT + 99 others); Wed, 17 Aug 2022 09:21:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239999AbiHQNUr (ORCPT ); Wed, 17 Aug 2022 09:20:47 -0400 Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03989646F for ; Wed, 17 Aug 2022 06:20:46 -0700 (PDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-332fc508d88so160781637b3.3 for ; Wed, 17 Aug 2022 06:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=1v5neMWckuuShK6mxvtzPriWYlr3sXVhkVDSWSsmeJw=; b=LDBMjmyDy8+FDV3nm9ieFIcEOzftkGrbLw3qls7qDOg57uj5JOl8BBzSFCjY8jOKOS 2PE+eweJ3KSdpM4J1jB90d65QSuMaBKUMizxx8nk4jvDILIROvgNKriJVB3YeaFlMbqG F3C4vnGDHVPdALDJBwXoKoGuotIJqPNzFEhcJFY2JS5GWbMPLpDDvjB66Lcij2GU5sc1 SV3COkXpVGgaae1stBGSPY0Com8ch3WfcBdkqfJU0bnN+xsEqXzRZ/IwQ4SJMoi2KtEp ODa0Z4O6ARQhdVNbtQ3a6JgZD+hRIpaAwAvAlKwph8YGc3t3zKqkmE8l9IpaTzWyTWyT xROg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=1v5neMWckuuShK6mxvtzPriWYlr3sXVhkVDSWSsmeJw=; b=p5mrGZx2WVow8tlbQcXHX/wCvLSs3fPXI0Kyu+IEPYx+RE4iOiJwFHBSuz3rLkePv3 x1M2lN1jhieRT9iCVE2N6FXSWr/DTZLJuz8zyE4YIxmFx/7NY0QZgs6q8yaqvelPdur0 pZRVfwI+5g6EyDcXGWGvZPSmWZKrRqeziYe+QUjrPyLUSq/GL0mClWYQp4a99QOOkGGJ eSo3njkYodlog5WvlYNSpdyzJzizWiUydbDJrlpkDWnmTqR9ttT1j/ag06FxT+wKGyTl DBxwVxH9275y6jHD+Fmqix0/8O4UujypEFjFvtTXLunGuKJzuI0irv40j8Uu6VpvouTV UKVQ== X-Gm-Message-State: ACgBeo1Umbc/LhGRtT5pxqkjAIIQf75ob3GEJBLMSyTRfmlBiLnLjSOD pIWagiG9z7QcYNLkY7nSoDQiZjH6anTSGlhfF+6QPQ== X-Received: by 2002:a25:2fca:0:b0:68f:aa4f:4a41 with SMTP id v193-20020a252fca000000b0068faa4f4a41mr4182720ybv.403.1660742445179; Wed, 17 Aug 2022 06:20:45 -0700 (PDT) MIME-Version: 1.0 References: <20220810223313.386614-1-libo.chen@oracle.com> In-Reply-To: From: Vincent Guittot Date: Wed, 17 Aug 2022 15:20:33 +0200 Message-ID: Subject: Re: [PATCH 1/1] sched/fair: Fix inaccurate tally of ttwu_move_affine To: Libo Chen Cc: Peter Zijlstra , mingo@redhat.com, juri.lelli@redhat.com, dietmar.eggemann@arm.com, mgorman@suse.de, linux-kernel@vger.kernel.org, Daniel Jordan Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 15 Aug 2022 at 21:19, Libo Chen wrote: > > > > On 8/15/22 04:01, Peter Zijlstra wrote: > > On Wed, Aug 10, 2022 at 03:33:13PM -0700, Libo Chen wrote: > >> There are scenarios where non-affine wakeups are incorrectly counted as > >> affine wakeups by schedstats. > >> > >> When wake_affine_idle() returns prev_cpu which doesn't equal to > >> nr_cpumask_bits, it will slip through the check: target == nr_cpumask_bits > >> in wake_affine() and be counted as if target == this_cpu in schedstats. > >> > >> Replace target == nr_cpumask_bits with target != this_cpu to make sure > >> affine wakeups are accurately tallied. > >> > >> Fixes: 806486c377e33 (sched/fair: Do not migrate if the prev_cpu is idle) > >> Suggested-by: Daniel Jordan > >> Signed-off-by: Libo Chen > >> --- > >> kernel/sched/fair.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > >> index da388657d5ac..b179da4f8105 100644 > >> --- a/kernel/sched/fair.c > >> +++ b/kernel/sched/fair.c > >> @@ -6114,7 +6114,7 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p, > >> target = wake_affine_weight(sd, p, this_cpu, prev_cpu, sync); > >> > >> schedstat_inc(p->stats.nr_wakeups_affine_attempts); > >> - if (target == nr_cpumask_bits) > >> + if (target != this_cpu) > >> return prev_cpu; > >> > >> schedstat_inc(sd->ttwu_move_affine); > > This not only changes the accounting but also the placement, no? > No, it should only change the accounting. wake_affine() still returns > prev_cpu if target equals to prev_cpu or nr_cpumask_bits, the same > behavior as before. Looks good to me Reviewed-by: Vincent Guittot > > > Libo