From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 55D1420C490 for ; Mon, 16 Mar 2026 10:55:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773658552; cv=none; b=aEM8FOyvjXRNJtj1tMkY02qyQrLff/9EdR7Xt0o+5i481qdzobWX3H1rNmu0DRGIUlc1WpOy9bFodFIvmjF8nFZNlUMSKNCM8tzqdOdn2n7zbKcOexV/CzWrr5dO09wPZN1Xl04PW1NJQqKjhoKRKpXK4/YYTGG3KL3yFUYr9HM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773658552; c=relaxed/simple; bh=yb1kqkOBmYZyBUxzt0kHkbIxIm7TwUuWujblsdUz+14=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=PoHc6Ka/BPNv+2P92LS1Aq5ViSTL2Ltx9dFs3Lfm2905B/+t7gErajzuZpQVzr/Q3d6cicU0Jbnb1SAlY1femKdskvvMVMjAN5Twd0V4BMwVjRgQ55zgyNLOclNkQ6tPDhAWwTU5ziBJg0KZIwUxb91dplnYada+HN3GDJY/zzA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CWmLAlUN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CWmLAlUN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91C0BC19421; Mon, 16 Mar 2026 10:55:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773658552; bh=yb1kqkOBmYZyBUxzt0kHkbIxIm7TwUuWujblsdUz+14=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=CWmLAlUNHBBVT9TCd3mSiD0hoD0s7euT8qchRJn3c4Z+98xVYOSucvQwauYWM4dbS x9m9Tm9ytJ1jT3Bh8DB4hzttJTQgxlw3pD3EL7pJ1Oxy5iJc6zvT7AOCDnOzXBPQic frIrzA0fkIrF44JyraGP5MPHOYVJaMab8/kRCTjLd4rq4IqOiBI93iF89rtkk7q3FQ wShsJxxaG7pj/43y1i/bKqnT29XaOwJEqRNg6MoKUF3RG9oAxbfO+XwcUfkqk0/yjY fncwEN7FF9BllzBe4gr06IzqmB1joyaKOf+Hu/qlqqex+4skYaA57RoKXtND6eG5sf Rudie+7d5SIUg== Message-ID: <2d3ff0fc-17a2-4425-b949-b5100251f98e@kernel.org> Date: Mon, 16 Mar 2026 11:55:46 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: "Vlastimil Babka (SUSE)" Subject: Re: [PATCH v2 2/5] Introducing qpw_lock() and per-cpu queue & flush work To: Leonardo Bras Cc: 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 References: <20260302154945.143996316@redhat.com> <20260302155105.214878062@redhat.com> <26662caf-de09-4f13-b374-dc7f879b7829@kernel.org> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 > > >