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;
Date:   Thu, 25 Aug 2022 13:00:03 +0530
From:   "Gautham R. Shenoy" <gautham.shenoy@amd.com>
To:     Libo Chen <libo.chen@oracle.com>
Cc:     mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org,
        juri.lelli@redhat.com, dietmar.eggemann@arm.com, mgorman@suse.de,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] sched/fair: Fix inaccurate tally of ttwu_move_affine
Message-ID: <Ywck+3E0DyNdUJRE@BLR-5CG11610CF.amd.com>
References: <20220810223313.386614-1-libo.chen@oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220810223313.386614-1-libo.chen@oracle.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?eq9CAw3JXfalbfp2zf5BAxduB4+fjjkT66kqAKWjlh280+XzNhGF1slN+FNK?=
 =?us-ascii?Q?uoyhMJqJnY0WfCh+fq7g/shlSdsob+ILxZIApmSk5owmHNZBYZFSsUJB9n7x?=
 =?us-ascii?Q?GJWKcLBgFhgv+vVBxnWr7KcoqTecRyRu6vwD9EQ+sqpCCU4FWbQxttGm0M9h?=
 =?us-ascii?Q?N6JfLtlDENbeaaQbnBrae7UP6I2IAN+EULr6UZQXxU6yn6lNrQb6MO9Necsz?=
 =?us-ascii?Q?cy3b6ZXcjdU6RmXTK35FphPGK+OCMt5z4dy15DHjN0TYGSowTU9qSb04pzas?=
 =?us-ascii?Q?MPMAm7wzt81z0xA5CzMWqwuNXH5w3GH48qSAMboCD/GZQZSRv+rRCvBM7Bdx?=
 =?us-ascii?Q?orZn/pNQrfdClmQRxkf6cH8uYv4PUqO/j/b2bpO4H5L63f/BkHAJFYSsuLca?=
 =?us-ascii?Q?eoY/WI30hQXlln6IIoq6azl6gwOhC1N3ZjtqjkHAGLjjzvglGSHiZMNsGJRQ?=
 =?us-ascii?Q?oyKCAWLHqMapVEsL+k6vkXSIr+ZopvvPn00nIMnqFjnXCwqJzb1GiTsUMuPq?=
 =?us-ascii?Q?P4DOfnI61QUyW/VPIL9vm+DdfDwgXBoGv3rql+/vr6KvEZPTFsdkVFdAjZSY?=
 =?us-ascii?Q?0Q3hxk2aSFl73yUMp190FmhD2pOvF9P5XZlrhh8wGXu8Eq/piJNlDQwwHS75?=
 =?us-ascii?Q?lRsCXYtkcrRMqygAu0/TztG9qcMHHUe6RyXYjce2UhINkrTC+yliMJQJBC0d?=
 =?us-ascii?Q?1Q9SCw/GbsT6oHorVPfHrbLu0K15b5I80nkYZMO92qjPhySk0nQZbqGdSDIr?=
 =?us-ascii?Q?c9Z6OHGWM2ubeyYurhNfSaoijLGhGB3fCcOBEsalPZJ+M0jQyWv3xclRL8KR?=
 =?us-ascii?Q?CF1T3woYKV4PPyXV2QXIBjhTrTduyl1HeE40aqUoX7YZN/CKn802P9WIzNvt?=
 =?us-ascii?Q?zHU8Lc+VsmELpyDobUBEEUhbiMzQr9iieILFhtULEDUkF/MbMBaAubHVcJ8j?=
 =?us-ascii?Q?8U51jV6tHYb/7BKMzL/vU0Z6TlKYjeJsmJT+RHFn73NYGwtOKrR6/PCgeUHu?=
 =?us-ascii?Q?5N0sl+G95bdcge0yPEG3q+YUB3Hkl0Vj7mM/i4klctjTM8x9rEgkcoE7ka8o?=
 =?us-ascii?Q?DPUuw9e3Mtgms+Meq5SO6TVYD3lPwJPCPi2aMUKXTVL3AxuyP35+h/9HqE5N?=
 =?us-ascii?Q?Xyd0dykc1HEtp3PxQvhFnOzhc456xn1AwaAfAmLMpLzhIdi4E5EYVJRdkScr?=
 =?us-ascii?Q?Juv8QEhS5wRZA6Td07FgYwsjaBK0WIou1EGrcyaMPy3t0XKyHqf+E7nvnBbP?=
 =?us-ascii?Q?zdda2KEsm2LLFUUM+psngyOmSsO+5UUfAHmiw7vCFK7Cnw5VTrl2CwVMqDee?=
 =?us-ascii?Q?9Je0C8Ra6NgzQ1XT91UztQNrUC2Cu97pFUqVYIhcursRWDJImaK5xlSMX2M5?=
 =?us-ascii?Q?YxhB8tY+bvYUTUUS/lp8kS6ZiTypucNny4suIZDxcuBlGwqpwb7UYObuGt5Q?=
 =?us-ascii?Q?T01IlfbtckIq3c/jxd9WsHT+qSMHH4NuWUZVI7FOwrtT3Xmdd4FVfont2uKd?=
 =?us-ascii?Q?KDA2Sm27Xpc9xEfjT1+9mXZyYKk2weflOp2GsSPnr9+UiVKpspBxh905Sa2e?=
 =?us-ascii?Q?nA4XYAmHdMUrunrEygcgdbjOCy4dQa5dZoHd1eiD?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ae578ffc-c960-476c-94e0-08da866ba7c7
X-MS-Exchange-CrossTenant-AuthSource: BYAPR12MB3286.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2022 07:30:16.5374
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 5/Ikk+ZAZTm3PE6T/WXLJTEmYrkmCj1GWHsNNtZpNkrrz4sWFsE7AMJPyEcsHti0W9BvNZ9zpYgLgg2vKG7f0Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1449
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,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 <daniel.m.jordan@oracle.com>
> Signed-off-by: Libo Chen <libo.chen@oracle.com>
> ---
>  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;


This seems to be the right thing to do. However,..

if this_cpu and prev_cpu were in the same LLC and we pick prev_cpu,
technically is it still not an affine wakeup?


>  
>  	schedstat_inc(sd->ttwu_move_affine);
> -- 
> 2.31.1
>

--
Thanks and Regards
gautham.