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 466963BAD90
	for <linux-kernel@vger.kernel.org>; Wed, 11 Mar 2026 07:58:10 +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=1773215891; cv=none; b=rzZ7+cB9LdcgsltU/l0sFXeiePBkEzimH9F72fKVo9hK3TlXp79wR6R1gI0Vzs7MdLReNFMPXbcF7U4LiuRR0UOd+CInHhdcx3CrEgLpDSXHw3FfC6cZ+fUOL4r39aUcW7saXB0dleclsboyosDxaNKGH2/jAXkryHa8RPBmX+8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1773215891; c=relaxed/simple;
	bh=E/Ts9ffHw1QTEDk6b85mzgFX+XeGE7mSX0ztncPCZhc=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=WfKO0Xd48KGW9nLQJ6tHwaUWd36lOe8vz1KlOP3ejN+yMtH3LcccpsGL2nr3GLLs38O2iSy2J04bNdjTbdhicDmGV9X7ku6YdADsdsAC8TREchBoTO/gjZK9I1IcQFpccLoAdyZrhITDsXRkWi30/91B00GgOazE8A8XC5x886U=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UZ47fYzb; 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="UZ47fYzb"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A8BBC2BC9E;
	Wed, 11 Mar 2026 07:58:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1773215890;
	bh=E/Ts9ffHw1QTEDk6b85mzgFX+XeGE7mSX0ztncPCZhc=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=UZ47fYzbLzv5Twpl9VBd5KCJKi2y9/sKpLbv6GEne7E5LtfMtUy01KGn7gYsLx77Q
	 NjqSJdMwdQcvnwse/iC/an96fMLUMOfvDcI8XdXvaTcp03FhWUORUWHq8rNBjVWYff
	 pBE9IGsAKkJAdSPcTgiQ7RHBaJoEWnOhzQtewGgFppIP49YEv2+09HMeC+0Hz8sFAL
	 z5eXLened+BzuY1aiIEu2mEl0ql8Ryqx5rfse1okUbGzH3AiOcnS16dV/iULqa6gZl
	 VBhT6cjcBaLLLbmVjYIv/u4wnSrcSIhZnGrk7eviNXvWqeVf7pQkliEYQFCJe1iwTx
	 nRzx/fJ4XY3fg==
Message-ID: <26662caf-de09-4f13-b374-dc7f879b7829@kernel.org>
Date: Wed, 11 Mar 2026 08:58:05 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/5] Introducing qpw_lock() and per-cpu queue & flush
 work
Content-Language: en-US
To: Marcelo Tosatti <mtosatti@redhat.com>, linux-kernel@vger.kernel.org,
 linux-mm@kvack.org
Cc: Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>,
 Roman Gushchin <roman.gushchin@linux.dev>,
 Shakeel Butt <shakeel.butt@linux.dev>, Muchun Song <muchun.song@linux.dev>,
 Andrew Morton <akpm@linux-foundation.org>, Christoph Lameter <cl@linux.com>,
 Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>,
 Joonsoo Kim <iamjoonsoo.kim@lge.com>, Hyeonggon Yoo <42.hyeyoo@gmail.com>,
 Leonardo Bras <leobras.c@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
 Waiman Long <longman@redhat.com>, Boqun Feun <boqun.feng@gmail.com>,
 Frederic Weisbecker <frederic@kernel.org>
References: <20260302154945.143996316@redhat.com>
 <20260302155105.214878062@redhat.com>
From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
In-Reply-To: <20260302155105.214878062@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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 <cpu-list> 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?