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 576A233EB1A for ; Tue, 3 Mar 2026 12:03:42 +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=1772539422; cv=none; b=oFWtc0EFAz/cbHqiX+vI8QOKOWObzGBlhvAITwBq9xv8P2ZfCdB9tm8lpaxa26eDoh6IIVK8f6Qj5Q59P6tYBGmh/EREIkK/r8TzuUNkGm60bTvem/TkwNCum02qC1nwHKpJ96PjVBAUqwkqWXo82O7COJ7/LR/GVZCH5rDMHOs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772539422; c=relaxed/simple; bh=FKgZyK3BHK2b7TxMxYTjWoMZ/Anv+R+QUIFrSIZF0a4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=utRtJHubhdJtiK0pmwql9JDh+iVEQd+E8kCBeMG+SEyw7Bj/7p6LrNM1wT8jVIPNQVIAK1UKXgpgKoiFh+wrtCQAvA6gUPyjb/Jvb7RiqffmJKFU/G97uWRb//jjSchpbFa06SknhFjdN/l689Xv8RbDdB8Ge23eGpZYKaSDoJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MJ5h64pR; 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="MJ5h64pR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39160C116C6; Tue, 3 Mar 2026 12:03:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772539421; bh=FKgZyK3BHK2b7TxMxYTjWoMZ/Anv+R+QUIFrSIZF0a4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=MJ5h64pRkNG7MTzmGfVUhEpIvCfLRPdDgZ+HBzr29YTlo8RuYyVEPMMwkfVPI7+tG DY1ce4MaKdmhWCcIeatCWo8nvAPDXexyLB/zjS+E+887Bp66ZOG4+I0bWDVY1EZCgO 6r01gWnEeqNknfBJGzMn50z0Z+zcnOsY83IHmFxMNZIo2mrOd9wEL2j9z9YgoYSZQ3 UAMDbSi+dLK/RX/lvyeXRmMo3+cobEko0BPtYh5rm1n/kGZDM2I2g9/KtJvovKaXPz Lce/xR+FgMd955QsHqTOEgDRroEfGcu5W7dZaVP4qGSpdn7vjiB+JFBo/So/MdMHDe Jf9wjqOSdajWw== Message-ID: <682380ba-c8f3-4023-928c-2152e934f8db@kernel.org> Date: Tue, 3 Mar 2026 13:03:36 +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 2/5] Introducing qpw_lock() and per-cpu queue & flush work 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> <20260302155105.214878062@redhat.com> From: "Vlastimil Babka (SUSE)" 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: > +#define local_qpw_lock(lock) \ > + do { \ > + if (static_branch_maybe(CONFIG_QPW_DEFAULT, &qpw_sl)) { \ > + migrate_disable(); \ Have you considered using migrate_disable() on PREEMPT_RT and preempt_disable() on !PREEMPT_RT since it's cheaper? It's what the pcp locking in mm/page_alloc.c does, for that reason. It should reduce the overhead with qpw=1 on !PREEMPT_RT. > + spin_lock(this_cpu_ptr(lock.sl)); \ > + } else \ > + local_lock(lock.ll); \ > + } while (0) > +