From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D74132B98F for ; Mon, 9 Feb 2026 20:48:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770670085; cv=none; b=DXwHvceBO5lWsmGUwkH80dm8lYeQJwREboBVdeeeBC5LoAncZgGPP0+SkgWIvD1l1ZZnfV7JsdDjWlXKeGlJy8EktwRVDrLkZBvRd3AicngW03JDL6nUpICFFzCQC9a0fsEHW7+QEqTDE2/WspSsvtWxSbB7SNLZ0gvcTeRNOHs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770670085; c=relaxed/simple; bh=zB0TgsTqPOUZ6c7fcWiP0FVWOC8g2W9dhEAU3gPWMZw=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=c1jtADpj7s4zGFcobe+L5LlNFzdDYwaeNbPrRqFZqPWzuFz7BxYNiiz7LME1HMif04e6WIHwZVkjcAxxcNtcC74QThJSCB/jxajH0cnnq+n6xLdZgaMW/9rYejBVvz7wRuPzdDyc1Eq4IiBwosIkgaLQh1pOlQil1pM5+Fi6tVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=PKlnI1dM; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=IPTip7RA; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PKlnI1dM"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="IPTip7RA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770670083; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BFz2HHJO0flQkCT+EP3v58+8Capft4jJvp38xn9xVew=; b=PKlnI1dMCJsxWkFptwU5VJUAl6TbeNrGk8HZaM2eTlpjvp3ymKxXN8T2Tcn3+JYbbnRXKC 5WcQvDmEBcWM65w/u5AWqGey3ooTY1zVmyWCgN1WEVHFc8TtKL/1yydJY9ocFwfeW0NDsi r+fJV6/QjV42Wbq7CS+m6VvztIgiYH0= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-498-kX6f9psuPwmBmBv4fPq_0g-1; Mon, 09 Feb 2026 15:48:00 -0500 X-MC-Unique: kX6f9psuPwmBmBv4fPq_0g-1 X-Mimecast-MFC-AGG-ID: kX6f9psuPwmBmBv4fPq_0g_1770670080 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-8c5296c7e57so1369832485a.1 for ; Mon, 09 Feb 2026 12:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770670080; x=1771274880; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=BFz2HHJO0flQkCT+EP3v58+8Capft4jJvp38xn9xVew=; b=IPTip7RALhcWS1iOeWM31mDs2IqIGhbfZ1vGqU4dHCijywTpZCSa3jpGiW9cdAKTuv 1tpIm+FrB5gcUls0SOX1YwtKvWcjTy59CVQVm0cYM1sq98iK9ipVKTrQMuvbMhySppsH esXfm4q20Lp9HXvO5QrI1NxZ858z3t+A/lRjEAuaLoxT2q1+Af/pXZ3BGuM73d5RhhZV fzZCg/7bCD9ED/YiXt4G2yXGe/jB5VJLyCvC2hVS+j0cTDVBwUAojERZM96nb9EtBiae Ui2/vnaHbZYlLBMHjNJrpIrEM57FuX3LDJCjSFr6yIXJnhMOEUbjPAiGleCAUPMZcENy 1ncw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770670080; x=1771274880; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BFz2HHJO0flQkCT+EP3v58+8Capft4jJvp38xn9xVew=; b=cdxWYHs8Pta9mvcElNRFpDtLE8m9cZzlnp+71MhCuvyHdYPYiDslm072JDDMlEPyO5 Mhq6UpL8zVvQQQtygimtTiyYUkgPhOzMOvjlUl84DtrHqC5IZ7rkikNxdZXpQX2jBOz/ InOeuqt6QfzzpekCJAqZ7GfF8YKP/ADDyqJBetcGIcHsq+oMuGvgtJKz8ydU71UNH90i UlxafnXDm3PQt2nMXvDO35av1mv2bBxcEDtVS/eyMD9MiRBja8Gn/zO3hw5/+8TsqDMs vJJwosPvjEm2ReqQ3hvX/wzmnxq0WdvN82Vaz43rlKY/q/v5bmo5q99S+6ylva1v6nyX 5J6g== X-Forwarded-Encrypted: i=1; AJvYcCUvkaGJcFaEVLUQVMIXZBWo5j7IIHBuUYdqjOyBLqKhlqslgRTXwSXAnDokB4zizgU8q0/XmIwIS2fzV90=@vger.kernel.org X-Gm-Message-State: AOJu0YwxhLpWkeemDvUBn2FnVXwdIPLy7Mmi61G+uE0/PxbkCCoJITve Ij3ma68jncRxAn+ndnxApR3iWvSqmXQUEZYfwA/e6RCNW8PSouXB0tRr3uTnV1hmfTdCCUw+hgx FgBE6rG7I4F+o+QINshc1+jbqy9RDq3Y29yozfhMfieFwS/WKq2BJ7NWklL4NlETyDA== X-Gm-Gg: AZuq6aKQycW21anm6PpRKYOoQSBlR3mKSmQl21cSiFrjU8m2C3MZHaTBFvgR6Aof07R to7/b34qexqKvrwccC0SiwbCuGTcRf1yQB6iUILpPYQ1pqI1sciCc7PjOIAzdrYViFF7CieYmiS WPpjsJSyie3n3CsKr1fUIJCsGl9mztel+GiC/Y0zXhHag24ulpzSpYK3HiU2x+uP4Hjb+T5cg9V cbKJMLiZzGKrz8B23Fof9N33MiAuwcpsjPSfZYjsdXB+yXe+gcZtJHHQiScGdGj6v7KQ3QqSsZo q5wAsLdv1Z58V8GpzwSHIT9gQQxPPsmtFPLBTJWQu0bKczZDmpcpB8b5i0gFYE7EytX3n+bFHNk +ahYzbcPBVR7HbW8yGkHZozJ3lDZDdWtNmDiwK+oRVvA/gJ3zzxlxCWDr X-Received: by 2002:a05:620a:3723:b0:8c6:d309:8801 with SMTP id af79cd13be357-8caf1bc28e0mr1629154185a.86.1770670080242; Mon, 09 Feb 2026 12:48:00 -0800 (PST) X-Received: by 2002:a05:620a:3723:b0:8c6:d309:8801 with SMTP id af79cd13be357-8caf1bc28e0mr1629150585a.86.1770670079848; Mon, 09 Feb 2026 12:47:59 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8caf982b811sm952627885a.29.2026.02.09.12.47.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Feb 2026 12:47:59 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <8d140b06-4e90-4c58-90dd-61aa5d1cbd5c@redhat.com> Date: Mon, 9 Feb 2026 15:47:58 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH/for-next v4 4/4] cgroup/cpuset: Eliminate some duplicated rebuild_sched_domains() calls To: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Anna-Maria Behnsen , Frederic Weisbecker , Thomas Gleixner , Shuah Khan Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20260206203712.1989610-1-longman@redhat.com> <20260206203712.1989610-5-longman@redhat.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/9/26 2:53 AM, Chen Ridong wrote: > > On 2026/2/7 4:37, Waiman Long wrote: >> Now that we are going to defer any changes to the HK_TYPE_DOMAIN >> housekeeping cpumasks to either task_work or workqueue >> where rebuild_sched_domains() call will be issued. The current >> rebuild_sched_domains_locked() call near the end of the cpuset critical >> section can be removed in such cases. >> >> Currently, a boolean force_sd_rebuild flag is used to decide if >> rebuild_sched_domains_locked() call needs to be invoked. To allow >> deferral that like, we change it to a tri-state sd_rebuild enumaration >> type. >> >> Signed-off-by: Waiman Long >> --- >> kernel/cgroup/cpuset.c | 20 ++++++++++++++------ >> 1 file changed, 14 insertions(+), 6 deletions(-) >> >> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >> index d26c77a726b2..e224df321e34 100644 >> --- a/kernel/cgroup/cpuset.c >> +++ b/kernel/cgroup/cpuset.c >> @@ -173,7 +173,11 @@ static bool isolcpus_twork_queued; /* T */ >> * Note that update_relax_domain_level() in cpuset-v1.c can still call >> * rebuild_sched_domains_locked() directly without using this flag. >> */ >> -static bool force_sd_rebuild; /* RWCS */ >> +static enum { >> + SD_NO_REBUILD = 0, >> + SD_REBUILD, >> + SD_DEFER_REBUILD, >> +} sd_rebuild; /* RWCS */ >> >> /* >> * Partition root states: >> @@ -990,7 +994,7 @@ void rebuild_sched_domains_locked(void) >> >> lockdep_assert_cpus_held(); >> lockdep_assert_cpuset_lock_held(); >> - force_sd_rebuild = false; >> + sd_rebuild = SD_NO_REBUILD; >> >> /* Generate domain masks and attrs */ >> ndoms = generate_sched_domains(&doms, &attr); >> @@ -1377,6 +1381,9 @@ static void update_isolation_cpumasks(void) >> else >> isolated_cpus_updating = false; >> > If isolated_hk_cpus is defined, I believe isolated_cpus_updating becomes redundant. Note that they have different exclusion rules. Other than that, you are right that "!cpumask_equal(isolated_hk_cpu, isolated_cpus)" should be equivalent to isolated_cpus_updating. But because of the different exclusion rules, there are restriction on where you can use one or the other. > >> + /* Defer rebuild_sched_domains() to task_work or wq */ >> + sd_rebuild = SD_DEFER_REBUILD; >> + > There is a potential issue: we defer all domain rebuilds here, including those > triggered by hotplug events which may change the isolation state. > > The problem is that functions like cpuset_cpu_active, which rely on the > scheduler domains being up-to-date—will, also be delayed. Is that okay? No, we are not deferring all domain rebuilds. We are just deferring domain rebuilds that involves changes in the set of isolated CPUs. Domains rebuild will still happen if there is no changes in the set of isolated CPUs. I need to take a further to investigate if this is a problem or not. Anyway s suggested in my reply to Federic, I am considering to not changing isolated_cpus due to hotplug events. In that case, this problem should be gone. Cheers, Longman