Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp3166416pxy; Wed, 4 Aug 2021 04:08:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz54jpXsDc1NpPLAIStuDyzuhQJWPXBgsWF5pRRTZMPA00Smx19zw34SfHY3UJ7QfmbX0D0 X-Received: by 2002:a17:906:919:: with SMTP id i25mr24350815ejd.171.1628075337471; Wed, 04 Aug 2021 04:08:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628075337; cv=none; d=google.com; s=arc-20160816; b=Y1X24g70FPef9WRkgnov6zm97dW0dIvFMR9IP0F8HadMITbhXZd3OsPOwIOg9vr7f2 d5WBKjW8+GhvU5/JtVqVP/4Yg4dFuA7T7GFOZIcp6CtkDnVpJiO36hN7/J563XPLiNyS Y9NlaJVgy/yBDx5z2hreEmkqFPpt1oL/UPXAnsWsUqg9sntBXlKbiYLUWAfHySAIg5CR uoeR9II74x/D9Wv/a0yR9F1bumPwkf95Hl4TMxvMkwQcmO20evp8n4skE9DvU8cBVrZM 1OmMV+GsMkrECNlYZSsoBDehZYlJVjn4RKDffmd039g2Ey07UwXIlLofXbwNC4jdnQuo 2nwA== 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=9u0RqsKRfoZbJEZQPnTMHGSd/igexR6Uk31qg02aG1g=; b=Augdm4Ij3+EyP3MqDw8Q1uuiLhxBiq4GU03p/cpA9hnwebA7Bleodyw9MFfTSU9LvJ 1cXhTQmmDDrSc2mRHHuJqXvmXMb6Tp1873YJ9wteNUajP1UuwqGMU2/1tqTDZ58q81R9 TkRVhk4O9YrDjbUvi5AspXoRkfrgc5WDhcXO9F7N8q2QyGeEFAYS+HXl3PQZ4b/WXKHV IEhW/YfxK/a32n4Sj42Q6LGIFeBU0fhPH38g5WtoMgkzV1WZvgtNDEkqyLqhqUps1vn4 2ilRWMSkZV5fkznwoWS1pBqeddkwgzMhBTxc4hxbCizjYCZakTKoMqvnkwQAlFkNF0wK C8/w== 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 l8si1731179edc.520.2021.08.04.04.08.34; Wed, 04 Aug 2021 04:08:57 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237298AbhHDK0a (ORCPT + 99 others); Wed, 4 Aug 2021 06:26:30 -0400 Received: from outbound-smtp25.blacknight.com ([81.17.249.193]:60327 "EHLO outbound-smtp25.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235383AbhHDK03 (ORCPT ); Wed, 4 Aug 2021 06:26:29 -0400 Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp25.blacknight.com (Postfix) with ESMTPS id 0E70ACAD34 for ; Wed, 4 Aug 2021 11:26:16 +0100 (IST) Received: (qmail 16267 invoked from network); 4 Aug 2021 10:26:15 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.17.255]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 4 Aug 2021 10:26:15 -0000 Date: Wed, 4 Aug 2021 11:26:13 +0100 From: Mel Gorman To: "Song Bao Hua (Barry Song)" Cc: LKML , Ingo Molnar , Peter Zijlstra , Vincent Guittot , Valentin Schneider , Aubrey Li , yangyicong Subject: Re: [PATCH 8/9] sched/fair: select idle cpu from idle cpumask for task wakeup Message-ID: <20210804102613.GC6464@techsingularity.net> References: <20210726102247.21437-1-mgorman@techsingularity.net> <20210726102247.21437-9-mgorman@techsingularity.net> <9dde989df06b483790cc24dc7670a919@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <9dde989df06b483790cc24dc7670a919@hisilicon.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 02, 2021 at 10:41:13AM +0000, Song Bao Hua (Barry Song) wrote: > Hi Mel, Aubrey, > A similar thing Yicong and me has discussed is having a mask or a count for > idle cores. And then we can only scan idle cores in this mask in > select_idle_cpu(). > Either approach would require a lot of updates. > A obvious problem is that has_idle_cores is a bool, it can seriously lag > from the real status. I mean, after system enters the status without idle > cores, has_idle_cores could be still true. > True. > Right now, we are setting has_idle_cores to true while cpu enters idle > and its smt sibling is also idle. But we are setting has_idle_cores to > false only after we scan all cores in a llc. > > So we have thought for a while to provide an idle core mask. But never > really made a workable patch. > > Mel's patch7/9 limits the number of cores which will be scanned in > select_idle_cpu(), it might somehow alleviate the problem we redundantly > scan all cores while we actually have no idle core even has_idle_cores > is true. > I prototyped a patch that tracked the location of a known idle core and use it as a starting hint for a search. It's cleared if the core is selected for use. Unfortunately, it was not a universal win so was dropped for the moment but either way, improving the accurate of has_idle_cores without being too expensive would be niuce. > However, if we can get idle core mask, it could be also good to > select_idle_core()? Maybe after that, we don't have to enforce > proportional scan limits while scanning for an idle core? > To remove the limits entirely, it would have to be very accurate and it's hard to see how that can be done without having a heavily updated shared cache line. -- Mel Gorman SUSE Labs