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 9AB3E35677C 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-2caced6038eso2470445ad.0 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=WwDSAxDgKilqX9RAzOIUY2dPuWKXuqRoZZWWjgsVsx1ic7+wChyhr+Lxq8hjpy1ek3 ml/VEVKKRVNOzepgDrxW0Jaa9hi/c7E4IkG6V63+fiLW4x3M/m2PWtqdDtHz3a26NSP6 H7vytkOPxXvfhfgKuD3hBiV5eTe+s6IQ9P+Jxxbu7uh5FOiBxXjtp3eKdrweu7TIKfCA mvMZd2FltfBKEsGZhVS0o6tHagi70hWG5EUPKiy5oreJ2hJQ9CGUyO3R02+T/XTnCv0J 6ZIqFWE5asC/ToUdVsgx4N7WvXnRy4Gar3hZvMbpF/r5QFsKq5WUrx1jl9OlAb78bjWD Sr4g== X-Forwarded-Encrypted: i=1; AHgh+RquVrx/Sm27TQg1o8xQzrHxY7R2mu7y4lS1cCERsdwZU1DlVWO24R+UjDdNemxrA9hJMvA=@vger.kernel.org X-Gm-Message-State: AOJu0YzVhVzNL3I3eM441RyRmTZMo0HsfP/NF2KI8HwcnWPhAaDXiu0t qijeCPBRNgYHHuBecDZMFSDXksLGMrxMF/A3v368MOMqtHNEUfOqPpgc X-Gm-Gg: AfdE7cmgtBKPQq1DDSuK7a/eICKZ2CgED83AFS77Qe2SRIuBmuXUAxbXAQqmG+Zayh6 ivKO+lvzXI6LICX+r9J3PQN5Vtq8HTI7i9lBADG8vcyemt3P5N17EnXueGcPytdyrUpCQm46oBd shQycPASezDVxwqT+S5VJoWhIp24cTyInBbzT+GSwGH7MAch5gxwfwqDxKm2Ts/F4EqP3AhQlzs w77e1s0o6rrla7x35GzVt3Cp7FZ2kjpg28/RxGNgfow0iMrOxUfqaVAWNGilIq7FRs3bjZ4CYQj w/6Qm3Pi/OKU5amN/lcMVxIXxIO1/b83kFclWkNcdpY8xpz4+v1+36SpTlYi0/G9a3Nd0EZc09y rvqG8J4xcPSv5z6AbNI+XBcjwsawtEXkA8swTN+8ZBM5pzr7edwvWzgS0NSnfaKzaTlZ9147Hmy Z5Cmf6ZAVaizrTSQftrQ== 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: rcu@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