Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3446860pxj; Tue, 11 May 2021 04:52:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzikNsLNbLZOaUygHIygh9jK6cfNhEHPLlIf75emjgJYOkPXb+uxUS3HEz5sq5i4qQjcTcp X-Received: by 2002:a6b:c857:: with SMTP id y84mr21697764iof.118.1620733945187; Tue, 11 May 2021 04:52:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620733945; cv=none; d=google.com; s=arc-20160816; b=gSbb2K8gXEC3zYLMIVX0FbZZAnUQ7dk4XdIxFN4uBTEdtNo3gicz76YvgsAfIdZKhS R2sNm6yXstfa1wZwSNtMURazEtq6kVz1c2NpNyhsTY0MOLsNpmyKL80zUIq0HhHKf92o LTJ/BuAc/J0Zj66ENCpVBg/GYWtaqYkncIRn/EB772cfsf0dbXzGEIMTX/nYDO63iJRl LA8b2imxMkTCw5U3iqOg4m+hyXEmVcdwfep3+JIPO4KyapvvtRQMn/HkszS/KEUNk+xs l+uxUqh5EwNif8GQB80U3REPpVYoZc2I8Ed1ri8mp0mqFYtuiKrS4ebIlUHPsVKzeVhS Prmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=XKuw1UkGQXzeDYxKF1tKL3Fq1/f6JzmOo7YuL01+nQ4=; b=KSksFpaBtncVmDKWt13UW/qXBGUmdL7j9EEweD5nXIOqaLT1tgXx6KlLi+hj2QuzN4 2trJpYmBi9Lko87pBAy/4NRt1ttrSR7c3PvXRZCoJgg+SGdWbKysJWqcsUD597Dq2D9L D+bDGsXhnUMNcdWuAAdGvSiPm/O01E/pY1LoKNuK8xMsYn4ipwJaEJNX44GnRlJmCETR qtGkW2koc+ZNy5YMYFCuVCBQbtn8nFHVU84lWg/6u9QYZJEeAOb/nV3Zhvqj7qNXbvlq N7V+4a5tjBwO1k5L87FFTesQW98Z4vA0qrm5WiDaTS4C5MG0Nuh9x7XxZtgxDxOx5QeK Fl1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r10si198563ill.70.2021.05.11.04.52.13; Tue, 11 May 2021 04:52:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231424AbhEKLwk (ORCPT + 99 others); Tue, 11 May 2021 07:52:40 -0400 Received: from foss.arm.com ([217.140.110.172]:45948 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230519AbhEKLwj (ORCPT ); Tue, 11 May 2021 07:52:39 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AFDA4D6E; Tue, 11 May 2021 04:51:32 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 23E3D3F719; Tue, 11 May 2021 04:51:31 -0700 (PDT) From: Valentin Schneider To: Srikar Dronamraju , Ingo Molnar , Peter Zijlstra Cc: LKML , Mel Gorman , Rik van Riel , Srikar Dronamraju , Thomas Gleixner , Vincent Guittot , Dietmar Eggemann , Gautham R Shenoy , Parth Shah Subject: Re: [PATCH v2 2/8] sched/fair: Maintain the identity of idle-core In-Reply-To: <20210506164543.90688-3-srikar@linux.vnet.ibm.com> References: <20210506164543.90688-1-srikar@linux.vnet.ibm.com> <20210506164543.90688-3-srikar@linux.vnet.ibm.com> Date: Tue, 11 May 2021 12:51:26 +0100 Message-ID: <87v97p1oap.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/05/21 22:15, Srikar Dronamraju wrote: > Scheduler maintains a per LLC info which tells if there is any idle core > in that LLC. However this information doesn't provide which core is idle. > > So when iterating for idle-cores, if select_idle_core() finds an > idle-core, then it doesn't try to reset this information. > > So if there was only one idle core in the LLC and select_idle_core() > selected the idle-core, the LLC will maintain that it still has a > idle-core. > That would be rectified at the next select_idle_cpu() call, so that would be a fight between extra instrumentation overhead vs extra work at next wakeup. > On the converse, if a task is pinned, and has a restricted > cpus_allowed_list and LLC has multiple idle-cores, but select_idle_core > cannot find a idle-core, LLC will no more maintain that it has an > idle-core. > This however does sound icky. > As a first step to solve this problem, LLC will maintain the identity of > the idle core instead of just the information that LLC has an idle core > > Along with maintaining, this change will solve both the problems listed > above. However there are other problems that exist with the current > infrastructure and those will continue to exist with this change and > would be handled in subsequent patches. > > Cc: LKML > Cc: Gautham R Shenoy > Cc: Parth Shah > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Valentin Schneider > Cc: Dietmar Eggemann > Cc: Mel Gorman > Cc: Vincent Guittot > Cc: Rik van Riel > Signed-off-by: Srikar Dronamraju > --- > @@ -6127,7 +6129,8 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t > { > struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask); > int i, cpu, idle_cpu = -1, nr = INT_MAX; > - bool smt = test_idle_cores(target, false); > + int idle_core = get_idle_core(target, -1); > + bool smt = (idle_core != -1); test_idle_cores() tells you if there's at least one idle core in the target's LLC. AFAICT get_idle_core() only tells you whether the target's core is idle, which is not the same thing. Note that this code has recently been changed by Rik in c722f35b513f ("sched/fair: Bring back select_idle_smt(), but differently") so as annoying as it is you should probably go try this out / rebase your series on top of it (as a rule of thumb for core scheduler stuff you should use https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git -b tip/sched/core as a base).