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 DBA7632ED2E for ; Tue, 3 Mar 2026 12:07:21 +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=1772539641; cv=none; b=c1ookByv4RxdBZWDdg9RwHoQA6NXEs9HA+xGT0IWuxlgrnvn16dh60Wkeom0yHb+iyMbfVwk4nqmQYy5Zduu0RNDEC4z+bpVuV10bd/kLMMgm50cdDvehmygBEW45ICWvFlm22Zq0W+yVE/BDX4VYBor1dwMfRIKKVM6YGyxPVg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772539641; c=relaxed/simple; bh=OftZ/sLQ3XZObtm9KS4DhoduNw0kAtMoQOE5FA4IaC8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UxbuGnwIa+BS1S/Wfs22c644rA3p4arZ1mH5uJ4kVwg2PkTg2ShqIu34uMIP7gwsfPror/v7UqpFQqvo4E3NTYbeYYjrp/d0NxycBBRtA15v2go+rO/OQt9DV55NXEez0izZcipeGwdXTri0NvnmppiP3z3U85HGW8PNwZyY/kQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=koXv92vt; 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="koXv92vt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C156DC116C6; Tue, 3 Mar 2026 12:07:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772539641; bh=OftZ/sLQ3XZObtm9KS4DhoduNw0kAtMoQOE5FA4IaC8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=koXv92vtg4amiUxo+E0FB6Q3wlqRd/moYmVlVgLGl7KJOBS0EykVY9kqZU7NFKqHr tRvIT9kMlNhDsdj3OMQC7HhyrjIpMSValH9x0h3dPWSV5xf34IRQX+SmlTTPwqtioR +06E3876eK5keDwI2Lb11i+IP1Ao24EDQ4CvjqsPG/u2Yx2NNakh9XU43tGQFmuXmI I5TTpYK8CKiWUTj1AwrzsGgpQkyRM+ExYcM9CxP/EKkZ3N467fynD2n/Gdo+efmAb+ IrPocPEyo7xpm5hS1PZH5l0WqWOBRIHz31+W7HoiceCqxmODyVutSVGM1eOS1uZZuY mhDLmhe3bfgBw== Message-ID: <9c10f799-907e-47ce-8ffb-e196ab0bee7e@kernel.org> Date: Tue, 3 Mar 2026 13:07:16 +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 Subject: Re: [PATCH v2 0/5] Introduce QPW for per-cpu operations (v2) Content-Language: en-US To: Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: 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>, Leonardo Bras , Thomas Gleixner , Waiman Long , Boqun Feun , Frederic Weisbecker References: <20260302154945.143996316@redhat.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: <20260302154945.143996316@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/2/26 16:49, Marcelo Tosatti wrote: > Proposed solution: > A new interface called Queue PerCPU Work (QPW), which should replace > Work Queue in the above mentioned use case. > > If CONFIG_QPW=n this interfaces just wraps the current > local_locks + WorkQueue behavior, so no expected change in runtime. > > If CONFIG_QPW=y, and qpw kernel boot option =1, > queue_percpu_work_on(cpu,...) will lock that cpu's per-cpu structure > and perform work on it locally. This is possible because on > functions that can be used for performing remote work on remote > per-cpu structures, the local_lock (which is already > a this_cpu spinlock()), will be replaced by a qpw_spinlock(), which > is able to get the pe A process thing: several patches have Leo's S-o-b: but not From: You probably need his From: and your Co-developed-by: or some other variant, see Documentation/process/submitting-patches.rst section "When to use Acked-by:, Cc:, and Co-developed-by:"