Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp420906pxu; Fri, 4 Dec 2020 06:34:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJwLIglXU21SuBza7YprifTkxS8QKr8oQy+BI+S65FcrE/eYzYIKHJuOLBhW97QIsZXyW6Dy X-Received: by 2002:a17:906:22c7:: with SMTP id q7mr7374255eja.486.1607092489790; Fri, 04 Dec 2020 06:34:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607092489; cv=none; d=google.com; s=arc-20160816; b=H25ELhaf38hiDrhdWEcocIyQbxYJ5xuZ32S/7Mv68XzK2vsW7O0eqqoWEkEkzVZ6iV 6fXxxw4Cc8wxyXhSOCRqYoPyUeYSLOjd73fA2qAERCmpIdhJ9HSC4yGLOaONoeZ/13rU RLLVUFK/FbPs/1UbNm9GLb32auaCfH0U5d/VELbrGvNTdKvk8z4UB6dgyJ0Bjc45BO9v lytRkmdtfLtzlXhYZMexSe5cvkkQZlrp4m3hye2uAx0kUBhJUFbdGYvQYsQu9G/rFXHs e6kVccpvkIEMzxWwFHyc1aasMBW+yiFn50MaXugICa+qMI4v4P4+ZJHKVrBKRR4sOion ei8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=MSnyyYm0AxvaLSTbu1ObCtx+cScneXaD5xVSFbVHI6o=; b=XAHLWmcacJBBT4UxPNlBhHXFg7KDqel8YKj3RU1vCLUJVh/+h7M3hhTSgNIpiasj3H cN+BQsSVI04KmoimngK6r/eiIspOim0hQn+jmlCc80Enx1clTqWsFx9ALITR/IIEtLuK 1K5Da3kFDd0RxGfkXezbnsOr821XTzU6dhFcKI9zds5reH/eeEi7I8L5k6Tixd9kqC7Z fs1+j607MkX03oG00SfpyqSr+0VymTGS4JXxTBsDVISUIMXqtQcVLtxRo+egyy8X7jDL O2cjSH5vNFy2KkF06XeOh2Yx691Gjq1rvn7FqC71JUHJ1W8hlSCq22rR1gBnmEBTonK0 KOAw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s18si1608154eji.422.2020.12.04.06.34.25; Fri, 04 Dec 2020 06:34:49 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729261AbgLDOcJ (ORCPT + 99 others); Fri, 4 Dec 2020 09:32:09 -0500 Received: from outbound-smtp31.blacknight.com ([81.17.249.62]:42483 "EHLO outbound-smtp31.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726605AbgLDOcJ (ORCPT ); Fri, 4 Dec 2020 09:32:09 -0500 Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp31.blacknight.com (Postfix) with ESMTPS id CB1D1C0DF2 for ; Fri, 4 Dec 2020 14:31:16 +0000 (GMT) Received: (qmail 25023 invoked from network); 4 Dec 2020 14:31:16 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 4 Dec 2020 14:31:16 -0000 Date: Fri, 4 Dec 2020 14:31:15 +0000 From: Mel Gorman To: Vincent Guittot Cc: "Li, Aubrey" , LKML , Barry Song , Ingo Molnar , Peter Ziljstra , Juri Lelli , Valentin Schneider , Linux-ARM Subject: Re: [PATCH 06/10] sched/fair: Clear the target CPU from the cpumask of CPUs searched Message-ID: <20201204143115.GB3371@techsingularity.net> References: <20201203141124.7391-1-mgorman@techsingularity.net> <20201203141124.7391-7-mgorman@techsingularity.net> <20201203175204.GY3371@techsingularity.net> <20201204113030.GZ3371@techsingularity.net> <3d8a6d19-afac-dc93-127d-da6505402cdf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 04, 2020 at 02:47:48PM +0100, Vincent Guittot wrote: > > IIUC, select_idle_core and select_idle_cpu share the same cpumask(select_idle_mask)? > > If the target's sibling is removed from select_idle_mask from select_idle_core(), > > select_idle_cpu() will lose the chance to pick it up? > > This is only relevant for patch 10 which is not to be included IIUC > what mel said in cover letter : "Patches 9 and 10 are stupid in the > context of this series." > Patch 10 was stupid in the context of the prototype because select_idle_core always returned a CPU. A variation ended up being reintroduced at the end of the Series Yet To Be Posted so that SMT siblings are cleared during select_idle_core() but select_idle_cpu() still has a mask with unvisited CPUs to consider if no idle cores are found. As far as I know, this would still be compatible with Aubrey's idle cpu mask as long as it's visited and cleared between select_idle_core and select_idle_cpu. It relaxes the contraints on Aubrey to some extent because the idle cpu mask would be a hint so if the information is out of date, an idle cpu may still be found the normal way. -- Mel Gorman SUSE Labs