Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2484568pxu; Mon, 7 Dec 2020 07:47:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQYGLXQulidI/KKVSNIjygE8ElGqVFRMR0efHMI0nO+t9fZqDgGC1ZStf8x1AFfSUqrCqS X-Received: by 2002:a50:e688:: with SMTP id z8mr20879281edm.129.1607356028803; Mon, 07 Dec 2020 07:47:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607356028; cv=none; d=google.com; s=arc-20160816; b=HlswV+esZdS/cZBr7YXLMEBQCsz4WrQABuiJlCnbIl5eFCUttPBK/oIez3abIHZu/l KHL5/iH+PrXMlRBT56BbG+UIbxl9Ie1yg1PxvWoUOWRcCyA2lltfXAtpgwtkZlyMQ0dG UyP00YMB1xkBvkJcRXvwLnaplQx+KzlCFrsdJADH3fLgKfQT6PvRadYPzgyfKcDUyipr 6p5p0bOSpwvPoixA3JM9J0E4nZwajN1C9sKjz3J1YyS7RdgEJI3OrfRx2WEIKsoMOKNC YwcoqrfqZmMTEyjYf+s56vgpJmpjV439bvlkTL4SEfiyiZetdU7PHJd8GHwI11D5kG5H kR/g== 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=rpE1j1t7qfLp/5Jp/I1NrOSK6VAApUvRR3Dk9O3UihI=; b=INoysbOYHEUINn854eREotE5Jj3+xC8QnPtATDZxqdktcLKIvTNPbhFTOdJ6bwFJZw TthHrlEp1CtB3mhoK4AZaU3DI6X5niywzrrNveWvQjqouZdWIylscQIbjxTowxfWmuAu j/BLmnBAhEAI//IDqujfp7u8vJTPSb/9Ga6a7lE486uU0tyWas6t1MunmusB5Szf3U/a zMQK0fdZve80l4/xCdn7gDAY1ELgRV6DqVOH+3wlbxQ+Qvu2EfceVl43sIEA67IhoO/B pdVeka94v0nvmsrczBH2EJOnCX7sOEn6Raev6L/keWjIoI25iimtdjhKjmgSlcdvbDLV Zqfg== 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 q6si6543708ejb.731.2020.12.07.07.46.41; Mon, 07 Dec 2020 07:47:08 -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 S1726788AbgLGPnM (ORCPT + 99 others); Mon, 7 Dec 2020 10:43:12 -0500 Received: from outbound-smtp63.blacknight.com ([46.22.136.252]:56139 "EHLO outbound-smtp63.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726754AbgLGPnM (ORCPT ); Mon, 7 Dec 2020 10:43:12 -0500 Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp63.blacknight.com (Postfix) with ESMTPS id 1ECE2FA88F for ; Mon, 7 Dec 2020 15:42:19 +0000 (GMT) Received: (qmail 27896 invoked from network); 7 Dec 2020 15:42:18 -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); 7 Dec 2020 15:42:18 -0000 Date: Mon, 7 Dec 2020 15:42:16 +0000 From: Mel Gorman To: Vincent Guittot Cc: LKML , Aubrey Li , Barry Song , Ingo Molnar , Peter Ziljstra , Juri Lelli , Valentin Schneider , Linux-ARM Subject: Re: [RFC PATCH 0/4] Reduce worst-case scanning of runqueues in select_idle_sibling Message-ID: <20201207154216.GE3371@techsingularity.net> References: <20201207091516.24683-1-mgorman@techsingularity.net> 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 Mon, Dec 07, 2020 at 04:04:41PM +0100, Vincent Guittot wrote: > On Mon, 7 Dec 2020 at 10:15, Mel Gorman wrote: > > > > This is a minimal series to reduce the amount of runqueue scanning in > > select_idle_sibling in the worst case. > > > > Patch 1 removes SIS_AVG_CPU because it's unused. > > > > Patch 2 improves the hit rate of p->recent_used_cpu to reduce the amount > > of scanning. It should be relatively uncontroversial > > > > Patch 3-4 scans the runqueues in a single pass for select_idle_core() > > and select_idle_cpu() so runqueues are not scanned twice. It's > > a tradeoff because it benefits deep scans but introduces overhead > > for shallow scans. > > > > Even if patch 3-4 is rejected to allow more time for Aubrey's idle cpu mask > > patch 3 looks fine and doesn't collide with Aubrey's work. But I don't > like patch 4 which manipulates different cpumask including > load_balance_mask out of LB and I prefer to wait for v6 of Aubrey's > patchset which should fix the problem of possibly scanning twice busy > cpus in select_idle_core and select_idle_cpu > Seems fair, we can see where we stand after V6 of Aubrey's work. A lot of the motivation for patch 4 would go away if we managed to avoid calling select_idle_core() unnecessarily. As it stands, we can call it a lot from hackbench even though the chance of getting an idle core are minimal. Assuming I revisit it, I'll update the schedstat debug patches to include the times select_idle_core() starts versus how many times it fails and see can I think of a useful heuristic. I'll wait for more review on patches 1-3 and if I hear nothing, I'll resend just those. Thanks Vincent. -- Mel Gorman SUSE Labs