From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5B35360ECA for ; Fri, 3 Jul 2026 06:11:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783059110; cv=none; b=MWWW6P2WcY+igG9+Qbo3XxoVg9qnHePZYMpY/TN1vTmQ/JXd773a7c8Bt+z6p35OQRx8Q/XnzA8OplAdcwRQjvD5smcN//VyzXlle6ICt+VURipR+/NRADIPuywCPcZD7vDk3TQNtWhJvjqxqvBZkkgsLNCmMn7ssav3pXtvL+w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783059110; c=relaxed/simple; bh=jOhOP6zR2h/Ko2CFKX5hAJT4zH1NZT/juuyNlpCE0Lg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CjlBd+2ILQAWgyFNbUR6dqngfTTYo3Uqjt7yVjOBP6pPaIO1EUiDYirSGc+Du4Orp4Gwk6JbCN8NnnQxWq0SoqLYwSysBCEIfQJ+HS6naXkJgrsrsfqJIAiYibzaObhZhhYtS+F29G+vCe/eB7fE5+fbEpSbrHPq5Bv2MCsN1+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IL8OWiAY; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IL8OWiAY" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2ca265d6ca1so2485755ad.1 for ; Thu, 02 Jul 2026 23:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783059109; x=1783663909; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pFrb1IqVlH/teSzvkSHFKk5+RmoA+DXh7g7twprTIs8=; b=IL8OWiAYAZZADjusMjzXWq90HTnB9McJ3hlaB3Ws74uCO0Vgy4QwCjUoLNhszOfbcR Wcu3QVuCN+pk4qQbJ2lOq8IYRyVDp8h3Vh/8k7e5gtc7FEF8+aoMsST9IgUJjFow7wVF AbTbbG/Rtoe4X8Y7kxUFc3uXQF41LD2VW6d+pqIY0JWlasMnoXBVlaheO9tpiPtkI8EJ 2OewQDPwCwvd9NHov/l7QJAoFXn0AF4GTgIGMn/SVe7zTjfzvuwK3XaizDJBRbq4pfTT s6RCUMAKnY717O6QKSZf4yarg9DTsdJCTnigJ3MDl3v/sJMxrSAi8o+/lG/fH+TxUilE ZRVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783059109; x=1783663909; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pFrb1IqVlH/teSzvkSHFKk5+RmoA+DXh7g7twprTIs8=; b=mlkaJmNXsRGENsVS+SyQZrnTU9ytBS6PkZbispO/OoYGaOQ38bpbnrkOt9u4a90Tss hwzYZ8xh5zhlPVo9mlME5PRnWU2QQKDcCz7O0mREeN4IeZUIGalf2O8jgMFpsNOpGkU+ o148qfMFLRI8YSTdt7gbs2yHU+iY35HPey+bEBXHQvUDtBz0KM/ILsid/Wv+G1IloO9s wYV2/NwX4aWpZ2qQbRl7UDw7sv4gSvM+cWmLvn6VX6S2stq50hIDKGiozaSn13CKgkGs GXFwBMFGIXzlskvIkdV5OuwGQn9TgVv7MtC3WFmVU3ky0XKodWOZHTXRdTIYQs5gK0pB 6AeA== X-Forwarded-Encrypted: i=1; AHgh+Rp6KKh6yh1FUrN2gXVgSwIN07OFEr4hGCBtUnBRZmih8RdyvL2kCyoTs+x/l3gcFd3s7movv6ED@vger.kernel.org X-Gm-Message-State: AOJu0YxbmQiFwecdrd2HHPLVBmsUaNqLUahUJRhAZO7BIGiJybQZROYo jN83t0qMt2w+/4W5ahWzFJJb7AP2YdcV6Kk9Feo/Lowo6VRo7ig4NdT2 X-Gm-Gg: AfdE7cn6rXGUaI4gSoTbeCWTpjxaGqkBj+OTVY9RYcQsKw7yBWBkdzacE/n4E90n4RQ snqMVGDKJt5UV25x0dh51tj0IL//yPB0W4huKdz8KrjyTFuaKNOIEDwlPkU4sq6j1gfsSzKKuRn eLvABMY6GWAY01t55IvjtC6tXv2kG5YfdnxuSqD0BPRgyzG7gY1DirzzEOlIglae6rGTXeYrFh4 gX3YRptjHY+ft0TQoWJCbUc2+2eFZyCL7BUUipA99uXOu3KktS0N7knXZuFiRoItHXIlkrv/DA7 dMvZVnJBnvM3F6rN5+bkyVwzb/1SCXXi+Lep6DFHz/ej1+rW/eqEfvPAQ9dYvVbFpBsZAl20KTy HLUIfs04OQb1eGJwO07+oJn5kWhaInJbFCgaxcZusk/jVceQBGQwyRhZSf/ZcXgpbd8WbXGiOVm 0GZ5k3rjvWe0x6v/lVkQ== X-Received: by 2002:a17:903:904:b0:2ca:783d:c5dd with SMTP id d9443c01a7336-2cacacbc837mr35504525ad.8.1783059108851; Thu, 02 Jul 2026 23:11:48 -0700 (PDT) Received: from ubuntu.. ([138.199.21.246]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cad7871290sm4162635ad.65.2026.07.02.23.11.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jul 2026 23:11:48 -0700 (PDT) From: Jing Wu To: "Paul E. McKenney" , Frederic Weisbecker Cc: Jing Wu , Thomas Gleixner , Waiman Long , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, cgroups@vger.kernel.org, Qiliang Yuan Subject: Re: [PATCH-next 00/23] cgroup/cpuset: Enable runtime update of nohz_full and managed_irq CPUs Date: Fri, 3 Jul 2026 14:11:42 +0800 Message-ID: <20260703061143.1658605-1-realwujing@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <4b9bfc1b-2724-4507-b2b2-81d71eb79841@paulmck-laptop> References: <20260421030351.281436-1-longman@redhat.com> <20260702033934.984512-1-realwujing@gmail.com> <871pdlphcc.ffs@fw13> <4b9bfc1b-2724-4507-b2b2-81d71eb79841@paulmck-laptop> Precedence: bulk X-Mailing-List: cgroups@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Thu, Jul 02 2026 at 16:07, Paul E. McKenney wrote: > wouldn't it work better to just leave all CPUs in RCU-callbacks-offloaded > state? Then you can adjust the nohz_full state of arbitrary CPUs without > messing with RCU. [...] > a continuous stream of race-condition bugs inspired the current state, > which is to allow this state to change only for offline CPUs. Thanks Paul. That is appealing, and we would much rather not wade into the online offload-switching races you describe. Let me lay out the one tension it creates on our side and ask how you and Frederic would like it resolved. DHM's aim is to enable kernel-noise isolation purely at runtime, on machines that did not pass nohz_full= / rcu_nocbs= at boot. "Leave all CPUs offloaded" needs the candidate CPUs to be in rcu_nocb_mask, which is only populated at boot. So the RCU part seems to come down to two options: (a) Accept a boot hint: require rcu_nocbs= (or nohz_full=) to cover the set of CPUs that may later be isolated. RCU is then never touched at runtime, exactly as you suggest. tick / timer / managed_irq / watchdog stay fully runtime-adjustable, so the "no boot parameter" property holds for everything except RCU offloading. (b) Change the offload state at runtime with no boot hint, which is precisely the online-switching problem you and Frederic hit, and what Thomas's lightweight-offloaded + CPUHP_AP_RCU_SYNC sketch would need to make cheap and race-free. We would lean towards (a) as the pragmatic first step: it keeps RCU out of the runtime path entirely, per your recommendation, and only asks the admin who wants runtime RCU-noise isolation to declare the candidate CPUs at boot. (b) / Thomas's mechanism could be a separate, later effort if a truly boot-parameter-free RCU story turns out to be wanted. Does scoping the RCU part to (a) sound acceptable to you and Frederic? If so, we will drop runtime nocb toggling from DHM entirely and just document the rcu_nocbs= expectation, leaving the other housekeeping types runtime adjustable. Thanks, Jing Wu Qiliang Yuan