From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 8D385186284 for ; Mon, 23 Mar 2026 00:51:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774227103; cv=none; b=aVbUnVC5mUt++mwg6tdE6qEUYXCrbjY8CsZ9kZ9jEmIPUR1rMruarYUbkeYWzD+kbWHr+81PI3NfxCPJvUa0K9VbRUG6zlFF5oWsJNHYiCzAYNLUfYO63g8us0wNRxqAWiMvIp8AEjFFfwfhB4gb8O9n58JOlzzUr1dKCvKxuo8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774227103; c=relaxed/simple; bh=i6bbCFhuAwooF9kQcvzGAszAt8EFcTZhC2Y9d/fm6CI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Disposition; b=AJD9csyUBYqpvNU/HVGgTHeOY3gD2m2p/nMfhr+foEqHIy4+i6pXqlitfC2h3PHzdORQSgrYoqH60WOFbu6tIPID2VGPAd8LB9glO1wYByGH3Ex6FpWq1KYYGv+Oe/IL9MIx29wy8uNaHoflgLfJUXNSonnhOhBlUWnuRRX6vfY= 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=DHnWGZZI; arc=none smtp.client-ip=209.85.128.43 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="DHnWGZZI" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4853e1ce427so23514535e9.3 for ; Sun, 22 Mar 2026 17:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774227100; x=1774831900; darn=vger.kernel.org; h=content-transfer-encoding:content-disposition:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=ESxewFgBZK9Bi/7rvM96reuYPehT0FaQvK288Q9oKH8=; b=DHnWGZZI9WchYcPjWuRYyi6km6YCG7Y1tPWkCO/M1MWbd2sMTnxrcmOP7RoxaGI9+s C4u0ddqV8gP+5DpVDcKzK0souTQndB9pl7Vwj0rCWWJ7rwpEpTfvkbAdQ+gKFPPw+Wa1 nHcd5v2EprYN/0rL2IoB8xPxkIUfXNYOs7meyF14SomQYbKSNHkmeAd9RxstlSj7Fcwa 6n3jkKkwBn73o12pSD70lUk7IgH/O5Hhc0z5ZgS5Wssmmhf1+PGqLJl4TFVgLE0DJYGV 3oEiEfzDPwL3STK1omNMfsrublHNiCWYPcULEyDr52t6C7xxeB57NB8boMMZxab2aM/Y yKvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774227100; x=1774831900; h=content-transfer-encoding:content-disposition: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=ESxewFgBZK9Bi/7rvM96reuYPehT0FaQvK288Q9oKH8=; b=R+foTsUV8zyZo3z4PmH54kewU5ForhFF/cEj1UixmqAiy56f2LTpBijS44gJruW8Zc mINGpim8l6R3mUsrKPfJuI4bKsCnX3qAqHhwM1Zac0I53JA6kugueln6szSVPA9m1pTs eUlKIZuNmhVHVzVpUwmf4CtkmNrCG2ekhoudnyYLhLBYkd8EuTlUZtUDQQEj7pQaKX7X 2uphsHtghdmNVBy5PSFsUC6gmrtn95DgGVKVeJlWg1Rg/QwEPQKFUfB975Q0oxidylCH KMzN37nKYOBa162mzqOC3X0Pbm/H0S/jWEo3u/7bxpScCsCucuW8GD3rISEjHxRGAOAN GLxg== X-Forwarded-Encrypted: i=1; AJvYcCXe+Ksu0+2ACG/9F6ZQHxfe2SHOBDSgVuHdXG0we4sD6br3Vy44UN7Et3F83PHfI72cuTkuNSQONhwtV7E=@vger.kernel.org X-Gm-Message-State: AOJu0Yzcak/qf+MNe3E8mmadU5/BrB2ogly9Nsxg47z70UpbwqNcIBhn Ex1+E9VHck3uzJ/teUTWN+A8kVwV9IBVfhqyer1665d+o7NcyZyWppXT X-Gm-Gg: ATEYQzz/75yUxWw0fEpHkYbX6RXvmW5sb/EmUTl3hi1SWutypK3xTI7A8tZgP7EGMtR qQ47MwN8k3ZXVb6hRrydtlpwRMZkMOqCM2A55jo6KwPVJTK9fJUOqTJ2FWXD7TUixcsQQd1jcsW Lvuo7c8Lgj37LWZBzXNPMPHXO1Lg6+bBmeSYOqxB3FSsUDY9fLLn2srSkfst+uCVmW9+Ckx2yPz /gj3qm0m9Of32ksDEQ8Q92W7w3yTh6lZg+aThbnPuJ7wmlW+cyorAExREqY9OLsEw2sz4rrF1kT S29Ug2Wzz3MDkCzUix/ODl0HHRrnzI9hcZOgTHcalt92U4tTrFvNV95MqnXYlk3U2NLsPSmdCUC mOes+EoyI/2QuW/CQenXOahyIJ5iVulzpGZ1YG8Vl2BMlXAPDdU7tBWiYUH0kXJxJ/SCmVnuhoK TYJHMA85b7rpEA+s06mh9MqFg876zSiU07FIs= X-Received: by 2002:a05:600c:c168:b0:485:40c6:f507 with SMTP id 5b1f17b1804b1-486ff04b4e9mr141252745e9.30.1774227099659; Sun, 22 Mar 2026 17:51:39 -0700 (PDT) Received: from WindFlash.powerhub ([2a0a:ef40:1b2a:fa01:9944:6a8c:dc37:eba5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486ff19d393sm71543635e9.16.2026.03.22.17.51.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Mar 2026 17:51:38 -0700 (PDT) From: Leonardo Bras To: "Vlastimil Babka (SUSE)" Cc: Leonardo Bras , Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Thomas Gleixner , Waiman Long , Boqun Feun , Frederic Weisbecker Subject: Re: [PATCH v2 2/5] Introducing qpw_lock() and per-cpu queue & flush work Date: Sun, 22 Mar 2026 21:51:30 -0300 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: <2d3ff0fc-17a2-4425-b949-b5100251f98e@kernel.org> References: <20260302154945.143996316@redhat.com> <20260302155105.214878062@redhat.com> <26662caf-de09-4f13-b374-dc7f879b7829@kernel.org> <2d3ff0fc-17a2-4425-b949-b5100251f98e@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Mar 16, 2026 at 11:55:46AM +0100, Vlastimil Babka (SUSE) wrote: > On 3/15/26 18:37, Leonardo Bras wrote: > > On Wed, Mar 11, 2026 at 08:58:05AM +0100, Vlastimil Babka (SUSE) wrote: > >> On 3/2/26 16:49, Marcelo Tosatti wrote: > >> > Index: linux/Documentation/admin-guide/kernel-parameters.txt > >> > =================================================================== > >> > --- linux.orig/Documentation/admin-guide/kernel-parameters.txt > >> > +++ linux/Documentation/admin-guide/kernel-parameters.txt > >> > @@ -2840,6 +2840,16 @@ Kernel parameters > >> > > >> > The format of is described above. > >> > > >> > + qpw= [KNL,SMP] Select a behavior on per-CPU resource sharing > >> > + and remote interference mechanism on a kernel built with > >> > + CONFIG_QPW. > >> > + Format: { "0" | "1" } > >> > + 0 - local_lock() + queue_work_on(remote_cpu) > >> > + 1 - spin_lock() for both local and remote operations > >> > + > >> > + Selecting 1 may be interesting for systems that want > >> > + to avoid interruption & context switches from IPIs. > >> Requiring a new boot option is always a nuissance. The cpu isolation is > >> AFAIK difficult enough to setup already. Could the default be that qpw will > >> auto-enable if there are isolated cpus configured? The option could still be > >> useful for overriding that automatic decision to both 0 and 1 for testing > >> etc, but not requried for the expected usecase? > > > > > > I think it's okay, as something like this? > > (should work for nohz_full and isolcpus) > > > > ###### > > diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c > > index 81bc8b329ef17..6c9052c28e3e4 100644 > > --- a/kernel/sched/isolation.c > > +++ b/kernel/sched/isolation.c > > @@ -170,20 +170,23 @@ static int __init housekeeping_setup(char *str, unsigned long flags) > > for_each_set_bit(type, &iter_flags, HK_TYPE_MAX) > > housekeeping_setup_type(type, housekeeping_staging); > > } > > > > if ((flags & HK_FLAG_KERNEL_NOISE) && !(housekeeping.flags & HK_FLAG_KERNEL_NOISE)) > > tick_nohz_full_setup(non_housekeeping_mask); > > > > housekeeping.flags |= flags; > > err = 1; > > > > + if (IS_ENABLED(CONFIG_QPW_DEFAULT)) > > + qpw_setup("1"); > > + > > free_housekeeping_staging: > > free_bootmem_cpumask_var(housekeeping_staging); > > free_non_housekeeping_mask: > > free_bootmem_cpumask_var(non_housekeeping_mask); > > > > return err; > > } > > ###### > > > > We would only have to be sure that this runs before cmdline parses qpw=?, > > I'm not sure it's possible to achieve this ordering with __setup calls, > unless one of them is early, and then it might be too early to do the > necessary action. > > > so user could disable qpw if wanted. > > > > Would that work? > > The pattern I'm familiar with is collecting all related params via > early_param() setting some variables, and then an init call (not tied to any > of the param) looks at those variables and does whatever is necessary. > > > Thanks! > > Leo > > > > > > > Makes sense, will take a look on that approach. Thanks! Leo