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.129.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 31E373F23B9 for ; Fri, 24 Apr 2026 18:33:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777055594; cv=none; b=eduPln4d/82DYjDKkGXotZ4OUtjfPpV4/pzzporeA5vlKuU0OvBjRq8K01gele7UZqVy8AkrwmEUFzvVicfK4GYbBEdcXjn9cTLJ8YbrKugOA/Uq0bUOodJYlDsE0F07kW2AXCQe5NPtOeHBljoGsgljTz65hXh/Olw5/GwlE+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777055594; c=relaxed/simple; bh=5KKtAI6jaBrVREHQpySmvtkbvTyy3jqrl7fEoimPtZY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Fn2+Et7FMVTJNbFW/ecf2j6owqQOffBZpaFXE3matXWBjljLeFCHychulptAVr6E1N2Z+UiciyM6d3KRdkP4I578ogKmYywcflbZJRZVAgnBM6rEa+W0ouCM293ebvw8w1hz3VEqKZKi1WXGqWNXzH9UWL5+0cT9QVwpxxp/Z5o= 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=YCvbU/1G; arc=none smtp.client-ip=170.10.129.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="YCvbU/1G" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1777055587; 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=/+Ofdg4jOEN9y2ToBzvsak04ExFbOMNwCGnfdG4OLXM=; b=YCvbU/1GAz/DJsA74fru/qeM1ldkg5IqTOq5LneRNbiS+Axz6fEFM/1rxQN7t7e8tcD1dE wBdJkD71kfGPMRkGWm7XesNBkY7CUGg/Mv2Y5p0W75u6IXi4ZALwWtiJgFJ1kUGs/5nMtZ 3w9xQMA4dqSK3A6fNoWiAzDfa9fz2JY= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-wNN_jrdwPo6U_kJxLlYKOg-1; Fri, 24 Apr 2026 14:33:03 -0400 X-MC-Unique: wNN_jrdwPo6U_kJxLlYKOg-1 X-Mimecast-MFC-AGG-ID: wNN_jrdwPo6U_kJxLlYKOg_1777055577 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D7825195608B; Fri, 24 Apr 2026 18:32:55 +0000 (UTC) Received: from [10.22.88.143] (unknown [10.22.88.143]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4304319560AB; Fri, 24 Apr 2026 18:32:45 +0000 (UTC) Message-ID: <2658f7a3-5156-4cc5-86c4-b23627e4b5f2@redhat.com> Date: Fri, 24 Apr 2026 14:32:45 -0400 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 19/23] cgroup/cpuset: Improve check for calling housekeeping_update() To: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Jonathan Corbet , Shuah Khan , Catalin Marinas , Will Deacon , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Guenter Roeck , Frederic Weisbecker , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Anna-Maria Behnsen , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-hyperv@vger.kernel.org, linux-hwmon@vger.kernel.org, rcu@vger.kernel.org, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, Costa Shulyupin , Qiliang Yuan References: <20260421030351.281436-1-longman@redhat.com> <20260421030351.281436-20-longman@redhat.com> Content-Language: en-US From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 On 4/22/26 9:10 PM, Chen Ridong wrote: > > On 2026/4/21 11:03, Waiman Long wrote: >> By making sure that isolated_hk_cpus matches isolated_cpus at boot time, >> we can more accurately determine if calling housekeeping_update() >> is needed by comparing if the two cpumasks are equal. The >> update_housekeeping flag still have a use in cpuset_handle_hotplug() >> to determine if a work function should be queued to invoke >> cpuset_update_sd_hk_unlock() as it is not supposed to look at >> isolated_hk_cpus without holding cpuset_top_mutex. >> > Currently, isolated_hk_cpus is updated within the cpuset_mutex critical section > (before mutex_unlock(&cpuset_mutex)) in cpuset_update_sd_hk_unlock. Therefore, I > think update_housekeeping can now be removed. That is true. I will remove in the next version. Thanks, Longman > >> Signed-off-by: Waiman Long >> --- >> kernel/cgroup/cpuset.c | 36 ++++++++++++++++++++---------------- >> 1 file changed, 20 insertions(+), 16 deletions(-) >> >> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >> index a4eccb0ec0d1..1b0c50b46a49 100644 >> --- a/kernel/cgroup/cpuset.c >> +++ b/kernel/cgroup/cpuset.c >> @@ -1339,26 +1339,29 @@ static void cpuset_update_sd_hk_unlock(void) >> __releases(&cpuset_mutex) >> __releases(&cpuset_top_mutex) >> { >> + update_housekeeping = false; >> + >> /* force_sd_rebuild will be cleared in rebuild_sched_domains_locked() */ >> if (force_sd_rebuild) >> rebuild_sched_domains_locked(); >> >> - if (update_housekeeping) { >> - update_housekeeping = false; >> - cpumask_copy(isolated_hk_cpus, isolated_cpus); >> - >> - /* >> - * housekeeping_update() is now called without holding >> - * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex >> - * is still being held for mutual exclusion. >> - */ >> - mutex_unlock(&cpuset_mutex); >> - cpus_read_unlock(); >> - WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN))); >> - mutex_unlock(&cpuset_top_mutex); >> - } else { >> + if (cpumask_equal(isolated_hk_cpus, isolated_cpus)) { >> + /* No housekeeping cpumask update needed */ >> cpuset_full_unlock(); >> + return; >> } >> + >> + cpumask_copy(isolated_hk_cpus, isolated_cpus); >> + >> + /* >> + * housekeeping_update() is now called without holding >> + * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex >> + * is still being held for mutual exclusion. >> + */ >> + mutex_unlock(&cpuset_mutex); >> + cpus_read_unlock(); >> + WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN))); >> + mutex_unlock(&cpuset_top_mutex); >> } >> >> /* >> @@ -3692,10 +3695,11 @@ int __init cpuset_init(void) >> >> BUG_ON(!alloc_cpumask_var(&cpus_attach, GFP_KERNEL)); >> >> - if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT)) >> + if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT)) { >> cpumask_andnot(isolated_cpus, cpu_possible_mask, >> housekeeping_cpumask(HK_TYPE_DOMAIN_BOOT)); >> - >> + cpumask_copy(isolated_hk_cpus, isolated_cpus); >> + } >> return 0; >> } >>