Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp756061ybl; Fri, 13 Dec 2019 04:11:55 -0800 (PST) X-Google-Smtp-Source: APXvYqx7Bcw3CHUoZ6EjTBaiQIt+JlZxlUNSB5BYOD5w6pMvBFnvopkjaEOkz9tNBScmj/rCqBfP X-Received: by 2002:aca:4c15:: with SMTP id z21mr6920076oia.12.1576239115204; Fri, 13 Dec 2019 04:11:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576239115; cv=none; d=google.com; s=arc-20160816; b=0dJWNJqa18LT7Wi3spQ0EKcBJrDqopbcZKg1Y1UXPueivZy8l7T8XfX+Q1nSUxCdaJ DhW6xDs2+YKfxU9UbjCbAMycaS416NPI0CsuKjZ5LwrcH4VFNvkM8cwwvjvCy6ac6Xpu RTNvK3+B92wOofQEiNvjR7I0V22X8knu7ElUrgV+1uYOjE+MTMiL8F2i7OpmmRR1E9BL THVZJ/BNxZLxqL4c3g7QCG7t4v4Aak8DW3dPR//ffM2Jz9L1UXujWLtcTmprBb/VlEe8 LSSmxT0yjSN6YdINqAsYcKbM2JOrZozA2J3qh6CsyF2HhUXs1up2wNWtY0vD+yDS8Qo7 sLGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Nr1I6SS3feCDCxDX98WOBu5+rrE0sIel3SECkfzkxLQ=; b=dFkHFk+SUty4F7VkoCXmYJwukcldjWPoVwKuNMQzh3mT9AvEeOt2YYzJiZUfRMi48i TmfSSqbEYMU0sPSQLJQIXnbzUnWvhViUptE52RAPbVOyuy64KNb4CoLjGXW33Ontp6LP r+jlZIYAV63EH9Zf3/EJsEpP9aVlVUm8QkDbwsOuB/pP5a0JdrYsnC6iz/1pmoDxjZ9G srxCb31MU2/RtpSvGhFRChGqDStUb5X0G+/D3rdsFaQvV2mAbHqDn78fepENEvnwniIQ Nffq3lAq8WlEgE7Bh0HO1hoCsyPbPLpE0hwuag1A/v2haaBRKtyH9PkMkYl5TJMkFXGM 1Eyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=QnHe2UaI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i78si5036998oib.1.2019.12.13.04.11.43; Fri, 13 Dec 2019 04:11:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=QnHe2UaI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726994AbfLMMJo (ORCPT + 99 others); Fri, 13 Dec 2019 07:09:44 -0500 Received: from merlin.infradead.org ([205.233.59.134]:48656 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726717AbfLMMJo (ORCPT ); Fri, 13 Dec 2019 07:09:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Nr1I6SS3feCDCxDX98WOBu5+rrE0sIel3SECkfzkxLQ=; b=QnHe2UaIVxReuM76bdKA79ENXD jnOHkBqFLlG4vig16AARH8jVMlLFarljq6FVA/8VUssKra++ftkU5+IT/qqaIo9fpJlRAFinnHeRK 8NE0VzhZgXyBj3HiFq2I6wKnVAyLD0PbqQ4y8xz7VdKECMin6Ys+V6F3S92nAB2h+bPFcT0Bx2kFK zSW9zbuee/d6ZPGLF5jV1JkJrU6cgzVlm5VbzANKYpO0fqV1tUJeXV5aHRLeZ6EubTRPx3ZTTFTrt sn1gEJCN7JVtYvCYpTGXHFxkxrQzIGA/6H9+mJmkHhtFAcfbHUjnqU8QgNnAVSPCujDRKODz5xdyJ oedNkF9w==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1ifjky-0003YE-Km; Fri, 13 Dec 2019 12:09:16 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id DDF9330602B; Fri, 13 Dec 2019 13:07:52 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A37B72B1886CA; Fri, 13 Dec 2019 13:09:13 +0100 (CET) Date: Fri, 13 Dec 2019 13:09:13 +0100 From: Peter Zijlstra To: Valentin Schneider Cc: "chengjian (D)" , mingo@kernel.org, linux-kernel@vger.kernel.org, chenwandun@huawei.com, xiexiuqi@huawei.com, liwei391@huawei.com, huawei.libin@huawei.com, bobo.shaobowang@huawei.com, juri.lelli@redhat.com, vincent.guittot@linaro.org Subject: Re: [PATCH] sched/fair: Optimize select_idle_cpu Message-ID: <20191213120913.GB2844@hirez.programming.kicks-ass.net> References: <20191212144102.181510-1-cj.chengjian@huawei.com> <20191212152406.GB2827@hirez.programming.kicks-ass.net> <6d188305-66ab-81cf-6340-34d155dcaf3b@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6d188305-66ab-81cf-6340-34d155dcaf3b@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 13, 2019 at 11:28:00AM +0000, Valentin Schneider wrote: > On 13/12/2019 09:57, chengjian (D) wrote: > > > > in select_idle_smt() > > > > /* > > ?* Scan the local SMT mask for idle CPUs. > > ?*/ > > static int select_idle_smt(struct task_struct *p, int target) > > { > > ??? int cpu, si_cpu = -1; > > > > ??? 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)) > > ??????????? continue; > > ??????? if (available_idle_cpu(cpu)) > > ??????????? return cpu; > > ??????? if (si_cpu == -1 && sched_idle_cpu(cpu)) > > ??????????? si_cpu = cpu; > > ??? } > > > > ??? return si_cpu; > > } > > > > > > Why don't we do the same thing in this function, > > > > although cpu_smt_present () often has few CPUs. > > > > it is better to determine the 'p->cpus_ptr' first. > > > > > > Like you said the gains here would probably be small - the highest SMT > count I'm aware of is SMT8 (POWER9). Still, if we end up with both > select_idle_core() and select_idle_cpu() using that pattern, it would make > sense IMO to align select_idle_smt() with those. The cpumask_and() operation added would also have cost. I really don't see that paying off. The other sites have the problem that we combine an iteration limit with affinity constraints. This loop doesn't do that and therefore doesn't suffer the problem.