From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 9AAB6350298 for ; Fri, 3 Jul 2026 06:11:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783059110; cv=none; b=mQzCI8JYPZk/zRsHyQR3xpHn0PBrWN+GX0GqE/ZkaRbUE1tx49UEuTCMaX3nMhBTuw3e/EDOJLPaw7emPtcU03oRbPugeJPHpMG/s1kmlzeq6Gc8phA6oyJ/+9KLDY+mquSJXLGq61aODo7AcAdblpAQ5dr2/omuzznFh2ku9Kw= 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.180 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-f180.google.com with SMTP id d9443c01a7336-2ca265d6ca1so2485775ad.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=lPJbClNRzle5FhcgYrDEXaydmQmpDkQFvidb94ljz6HvqUyyJbDIBXbVMwQuj2AHB3 oDXHKpja/Gcfjf9xTlcGC44qAb8hy0gDtTvpLWo23i/tD2TBtK1Dfe5ObubJOZr4IsbJ Yy3oTWWWtR8pqOkK5eDqDz5eUGfTqiRuyhvN/50a3T6wbzL6pfmAhaCIgXelf5aOmfBe +C4iLiS1ecumSy+XK47DJpKGyQ28l1Hs45zyeLTWib2nlTqEyQw6uCioKAe2XBXl+9Zq URtM3T2I4l3wYJLiOckpBZm3s3hOZzzqPcZj9+MxGYLF2ZNoXmZj1jNMpd+ZgHW8llZF 67NA== X-Forwarded-Encrypted: i=1; AHgh+Rqk0YmFk4vkoFYisTh6zJHOtynwQwmBacJEVLdIr0F5Q/LTroZ9TrMsuCIRFfOLgbAhFGx3DvpNwJinGoM=@vger.kernel.org X-Gm-Message-State: AOJu0Yy211DJsntkVkmp+PaJro1o4HfAiXGz6Et48BRTmcD7IAl93ppv WH8gQkbjgdseA8TDaOuLD+J46oFYadZchGZCcITSiCbNsHPalB83AvYV X-Gm-Gg: AfdE7clWOHBfjxBn/P+1km3VqCnGxzj3G2ggP7ku6RZmbgUzqJ8CrMwHaMqAXwl3Y1R TDeg3MjzLwHqbJyXV/KhVVdBE75PCnGJdEo5bCxCqjZPn1qxwbxYtMWthX9ErdsnqXQinrYduNf 243S8gyyui9wCOkZ1H7e0vgHu2o3OneqyuttLVZ5GjiWgZ+DOFgp2T9cp92GWrlM20mfQSOKvsJ SGiFB5HXVtwzvetPPXa4k528NDpzQzb32Yg91/FpSssOnai5jQ1iPbrKQ4FVnvRq84p55evbyql 9DoNToBxK/OhLX52jhJwObXtG1T3/48KpJt7R/33HgzaE9SqNs2T4YUBs9f8DtODbUuBP11zXLL Dx4irwyV9xi3t2nTohYyicdK+eM9eu8Y3glTFS+3TI7WZaqD+uP19bxwYY2Xv8eQucTdFVAP+fS zhM1gyQdv8GwERz4Dnrw== 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: linux-kernel@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