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 37FCF3793BF for ; Thu, 5 Mar 2026 19:27:26 +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=1772738848; cv=none; b=LtLNTha2bLkWJsZT9kCx7iAOjH/wX37OG9YGdCiNf7je5v5aJ91AAwoox/Eza4bQZv7/zq+Ix7tQe2aPwBu8w58arUqnmVrdhSz4O5ZfEXtEGPvOpiCtlnuWy7u3f9HJfufkK6ts8VE69dEvhaF6p86TmY1HAS9dyz12wZCYw3E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772738848; c=relaxed/simple; bh=tnekzAPZwkEBEkGCvEEtNGrcYKML/48LHk+kqouYDvU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=okLFwKdVHxbeEPWRTjT3sPiRXnJk6D9vDrqdr/DgJip66ypJs5NEhHuzm61rP7ElXF4cED/kzHDLobEMMfKac9iMC7Nw9WhZslGRO/v+mCCj+qMDa3N2ZwOsj8m1a2AVsX5FBm3PfZf4AeIP1DtIleAHjIjkf2t60zyCtJhR6KM= 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=faYt42iC; 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="faYt42iC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772738846; 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=Jpw5YL/yfmcf2nfXTWQb6UEHn1RiCuCH4uCU1DxxWmI=; b=faYt42iCzRdMftCGRaUjlQ6+axZk4tVyvdqhQwmyI9y/Qlr3YEhWGkXivOCdMSH/kWScdT L9YUNMxl53xMY3CRUyfWvutkudR7cDtHPl3xRM9qrThv3mvlqpdXT0gtgL7HjeuVOhu3eF i6/bEHfPMghznmxkfiMGnnAfo5ZyT8U= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-650-YKzTSNnvMXKV5U0hQVhGxg-1; Thu, 05 Mar 2026 14:27:20 -0500 X-MC-Unique: YKzTSNnvMXKV5U0hQVhGxg-1 X-Mimecast-MFC-AGG-ID: YKzTSNnvMXKV5U0hQVhGxg_1772738839 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D3D7918002CD; Thu, 5 Mar 2026 19:27:18 +0000 (UTC) Received: from [10.22.88.171] (unknown [10.22.88.171]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 40A60180049D; Thu, 5 Mar 2026 19:27:17 +0000 (UTC) Message-ID: <40efb05d-ec68-4677-b0a6-952a26f84553@redhat.com> Date: Thu, 5 Mar 2026 14:27:16 -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] cgroup/cpuset: Call rebuild_sched_domains() directly in hotplug To: Frederic Weisbecker Cc: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Jon Hunter References: <20260304184100.71015-1-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: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 On 3/5/26 8:54 AM, Frederic Weisbecker wrote: > Le Wed, Mar 04, 2026 at 01:41:00PM -0500, Waiman Long a écrit : >> Besides deferring the call to housekeeping_update(), commit 6df415aa46ec >> ("cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug >> to workqueue") also defers the rebuild_sched_domains() call to >> the workqueue. So a new offline CPU may still be in a sched domain >> or new online CPU not showing up in the sched domains for a short >> transition period. That could be a problem in some corner cases and >> can be the cause of a reported test failure[1]. Fix it by calling >> rebuild_sched_domains_cpuslocked() directly in hotplug as before. If >> isolated partition invalidation or recreation is being done, the >> housekeeping_update() call to update the housekeeping cpumasks will >> still be deferred to a workqueue. >> >> In commit 3bfe47967191 ("cgroup/cpuset: Move >> housekeeping_update()/rebuild_sched_domains() together"), >> housekeeping_update() is called before rebuild_sched_domains() because >> it needs to access the HK_TYPE_DOMAIN housekeeping cpumask. That is now >> changed to use the static HK_TYPE_DOMAIN_BOOT cpumask as HK_TYPE_DOMAIN >> cpumask is now changeable at run time. As a result, we can move the > But rebuild_sched_domains() will still handle the cpuset isolated partitions > somehow right? Sorry for the question, I'm a bit lost in the > partition_sched_domains() maze... For v2, generate_sched_domains() has no dependency on housekeeping cpumasks other that the HK_TYPE_DOMAIN_BOOT to strip out boot-time isolated CPUs from the effective_cpus of top_cpuset. So rebuild_sched_domains() will do the right thing even if HK cpumasks haven't been fully updated yet. Please let me know if you can think of any corner cases that will still be problematic. Cheers, Longman