Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp874027pxf; Wed, 7 Apr 2021 13:52:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdXzEZHiPO3RA0lFXVqYSvHgt1ytDcoVP26cPjffau8w8VWrrR1EuEjgp8m8qzj3O9/Y8q X-Received: by 2002:a92:d6cb:: with SMTP id z11mr4112192ilp.227.1617828732718; Wed, 07 Apr 2021 13:52:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617828732; cv=none; d=google.com; s=arc-20160816; b=gRVa1oRuorh4x5x4bJJNRWt6fcA3uYhYq0r6uvT7+xb/YZmoPIrndK6GviltNHvKx5 z7+9xZ4CpNPXdzFqXmj1d+bxsguJ5Fup0k6G6FFC26cKktJJlpSDvQiBTm1+qmQE7htI R8dnLirz6vHLKVOuUDvFCu081GFOcaQM2sZ4SH5plH1rcUVGwK9wordhwKkueqH/Bttk ylAfBBV+9M3PKJXmDxC2G4K11/MuqpRAE7dsNlgoTC1EffuVRBksTDAUGAswsUhC8q+5 DC4ClBc7ob5aWA8s6YbdE24CKoCiIXm5LMQTnIkt63TO+PYFFnTgk31c1NiCCoiQdzFx twLw== 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=Ntgbgq2aLu8qCUtedHecJylSBjrPf0oH8tdTqIYDGmU=; b=WP4GmhP9rt9Qn2pEGT3Mii9MrFjrWFT1VhOei4WKS2wxi5TOGoB2A5yh6YHTg5rw2p scdH4ezRzQ8BjXhqOUdpomJXBfNL220LmGHvwBf5ZbUB07/AYTEqp53GynACOr4DjxFr prgVU12Q2NP+PL//8LHa1VXT+5R6Cf74Az6j9qESvSbByIj2hZ6JupXVUWQRsfHIpYSq 0J3WZ1HGwTvpNfWGaieEnODNJjUGs2jmggmLQBd+rldRluRgVLuNeC/SuSQaP9ZJHhev EbDT/hCoDzy0+yr6No5ux9CAzhpIr8/AqzkEBIdz4jCQDkr6l/m6Gxz6v//rchMKgEsx NLJw== 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 a18si1976446ilc.120.2021.04.07.13.51.59; Wed, 07 Apr 2021 13:52:12 -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 S232860AbhDGKsN (ORCPT + 99 others); Wed, 7 Apr 2021 06:48:13 -0400 Received: from outbound-smtp17.blacknight.com ([46.22.139.234]:47551 "EHLO outbound-smtp17.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351434AbhDGKra (ORCPT ); Wed, 7 Apr 2021 06:47:30 -0400 Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp17.blacknight.com (Postfix) with ESMTPS id EA2E21C3867 for ; Wed, 7 Apr 2021 11:47:19 +0100 (IST) Received: (qmail 13079 invoked from network); 7 Apr 2021 10:47:19 -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 Apr 2021 10:47:19 -0000 Date: Wed, 7 Apr 2021 11:47:17 +0100 From: Mel Gorman To: Peter Zijlstra Cc: Rik van Riel , Vincent Guittot , linux-kernel , Kernel Team , Ingo Molnar , Valentin Schneider Subject: Re: [PATCH v3] sched/fair: bring back select_idle_smt, but differently Message-ID: <20210407104717.GD3697@techsingularity.net> References: <20210321150358.71ef52b1@imladris.surriel.com> <20210322110306.GE3697@techsingularity.net> <20210326151932.2c187840@imladris.surriel.com> <1e21aa6ea7de3eae32b29559926d4f0ba5fea130.camel@surriel.com> <20210407094106.GC3697@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 Wed, Apr 07, 2021 at 12:15:13PM +0200, Peter Zijlstra wrote: > On Wed, Apr 07, 2021 at 10:41:06AM +0100, Mel Gorman wrote: > > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -6112,6 +6112,27 @@ static int select_idle_core(struct task_ > > > return -1; > > > } > > > > > > +/* > > > + * Scan the local SMT mask for idle CPUs. > > > + */ > > > +static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int target) > > > +{ > > > + int cpu; > > > + > > > + if (!static_branch_likely(&sched_smt_present)) > > > + return -1; > > > + > > > + for_each_cpu(cpu, cpu_smt_mask(target)) { > > > + if (!cpumask_test_cpu(cpu, p->cpus_ptr) || > > > + !cpumask_test_cpu(cpu, sched_domain_span(sd))) > > > + continue; > > > > While I know that !cpumask_test_cpu(cpu, sched_domain_span(sd)) was > > done previously, I found it hard to believe that the test matters. If > > target/prev share a the LLC domain, why would the SMT siblings *not* > > share a LLC? > > I think the reason for it is that a cpuset might have split the siblings > apart and disabled load-balancing across them or something. > > Then the affinity mask can still cross the partition, but we shouldn't > ever move into it through balancing. Ok, cpusets do split domains. I can't imagine the logic of splitting SMT siblings across cpusets but if it's possible, it has to be checked and protecting that with cpusets_enabled() would be a little overkill and possibly miss some other corner case :( Thanks. -- Mel Gorman SUSE Labs