Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp3350387ybx; Sun, 3 Nov 2019 16:49:27 -0800 (PST) X-Google-Smtp-Source: APXvYqzYefdtsl/4FgfdIOkQrgPvx2JLN9ff0WglNz0TkXycW+Vwew3dAAN8G9+mLw9t52bUjBul X-Received: by 2002:a50:cc43:: with SMTP id n3mr26906704edi.287.1572828567683; Sun, 03 Nov 2019 16:49:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572828567; cv=none; d=google.com; s=arc-20160816; b=Lts88ys2Myv4rrBaAi5LPOiQsrfUVUwccr1zvKoAPfs5yPxQoBHGhJ5/utbBhgYo6y d4SHGbHAqtRsMe5ipoa6iH9AuWWpTxAiaISm2s5bfbGsbNEuisJrJeBbkhpICVmsQlhe 0l1yjLVUagFLnaheNj4NQqnT7vhqMR1w7qPTEORorlPkfJ4QfDYIcESXMxq4Q3fPifZA +jVNJI/Uxfo6qLvgGgypBNU2jd6lr9GUVnLYWVl1IVGsNSNj9NkYIUiftfqsPDlybH3V kmt3FIlIn8eZ6+xnIlwOA9HzUcbLO6B2ZfmsRLGVF3pn8wQcRoOxsaAgTnJdTtHQyNFy plxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=BLIIwZRSO0i2dTmAXKUo3VWRvgg9JyCKKv2J0HYUQUw=; b=KkJjcDPkVWAoK552KiGqHaamKMoHADp0QYX6OQUl1KetCyZM+YbA+c0S5iiSknigg5 tvxqZDCcelG1DMHyXHFK6HUFkI1FdapupK4CJgtZ2gvVXGMOi/6PR8yJeQ4Zd++SPwoL Z0tEsBEp/FT+Si5XHKVEvBiOvMMhg8ORJUOAFhz3rQUOkmD38rM1rKID5VxACE4ACFJq /GSWS6M73cyFyECgj9qrJ7hkC/sQCenZRlc6U0gdJHwDVqDDo+9yU+4XOWMCiSFmwDUj SZ6NOXXTy00g6jpxlBVwj2cytaLQag/T4eIT9BLSlnYj4/dyid1jPdrzWGttVkyIqUjl rLYw== ARC-Authentication-Results: i=1; mx.google.com; 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 f8si6036859edf.428.2019.11.03.16.49.04; Sun, 03 Nov 2019 16:49:27 -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; 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 S1728601AbfKDArz (ORCPT + 99 others); Sun, 3 Nov 2019 19:47:55 -0500 Received: from foss.arm.com ([217.140.110.172]:33508 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728277AbfKDAry (ORCPT ); Sun, 3 Nov 2019 19:47:54 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F1C1A1FB; Sun, 3 Nov 2019 16:47:53 -0800 (PST) Received: from [10.0.2.15] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2C4BA3F67D; Sun, 3 Nov 2019 16:47:52 -0800 (PST) Subject: Re: [PATCH v2] sched/topology, cpuset: Account for housekeeping CPUs to avoid empty cpumasks From: Valentin Schneider To: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Cc: lizefan@huawei.com, tj@kernel.org, hannes@cmpxchg.org, mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, Dietmar.Eggemann@arm.com, morten.rasmussen@arm.com, qperret@google.com, =?UTF-8?Q?Michal_Koutn=c3=bd?= References: <20191104003906.31476-1-valentin.schneider@arm.com> Message-ID: Date: Mon, 4 Nov 2019 00:47:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191104003906.31476-1-valentin.schneider@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/11/2019 00:39, Valentin Schneider wrote: > Michal noted that a cpuset's effective_cpus can be a non-empy mask, but > because of the masking done with housekeeping_cpumask(HK_FLAG_DOMAIN) > further down the line, we can still end up with an empty cpumask being > passed down to partition_sched_domains_locked(). > > Do the proper thing and don't just check the mask is non-empty - check > that its intersection with housekeeping_cpumask(HK_FLAG_DOMAIN) is > non-empty. > > Fixes: cd1cb3350561 ("sched/topology: Don't try to build empty sched domains") > Reported-by: Michal Koutný > Signed-off-by: Valentin Schneider > --- Sigh, this is missing: v2 changes: - Fix broken diff At least it *does* apply this time around. > kernel/cgroup/cpuset.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > index c87ee6412b36..e4c10785dc7c 100644 > --- a/kernel/cgroup/cpuset.c > +++ b/kernel/cgroup/cpuset.c > @@ -798,8 +798,14 @@ static int generate_sched_domains(cpumask_var_t **domains, > cpumask_subset(cp->cpus_allowed, top_cpuset.effective_cpus)) > continue; > > + /* > + * Skip cpusets that would lead to an empty sched domain. > + * That could be because effective_cpus is empty, or because > + * it's only spanning CPUs outside the housekeeping mask. > + */ > if (is_sched_load_balance(cp) && > - !cpumask_empty(cp->effective_cpus)) > + cpumask_intersects(cp->effective_cpus, > + housekeeping_cpumask(HK_FLAG_DOMAIN))) > csa[csn++] = cp; > > /* skip @cp's subtree if not a partition root */ >