From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4BA4DCD1288 for ; Wed, 3 Apr 2024 06:20:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B55C16B0087; Wed, 3 Apr 2024 02:20:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B04AE6B0088; Wed, 3 Apr 2024 02:20:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CC996B0089; Wed, 3 Apr 2024 02:20:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7D2716B0087 for ; Wed, 3 Apr 2024 02:20:01 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0963F80980 for ; Wed, 3 Apr 2024 06:20:01 +0000 (UTC) X-FDA: 81967220202.22.2635A61 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf26.hostedemail.com (Postfix) with ESMTP id 176F6140008 for ; Wed, 3 Apr 2024 06:19:58 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=bMfqNrGO; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712125199; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=N6GmseYnDR4+V902wKBjRYx3D3EiRB4hYzZswSQsvkk=; b=4nJRVf19V86ThMzKkclBuLmUQJf0gVVbZ7yuCHWd3xgdZOg0BYiQICfrhPSHPTBHtIs6lm 6eAlVR5/VIYlAi+p8N20Og3b+HcsvcpgWb+PG6ekdq4j0iunSgWH1jGRN5bZwVhX9+vcLp 0awFb9/0AMRQRYyOvFqMZiyajM0Ok0o= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=bMfqNrGO; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712125199; a=rsa-sha256; cv=none; b=qVlqia12DBGEUcO2TH9g9iUOhxIQUfUCLLX/fwWgLv13+IkXbeuElGUFWosIgz/NvoW2w9 zVGHFcHiOyOYAJEhIpUnz0B8s0UCBxEYKoZcmag1gLKAO5g7Oq0TTGvkukqGoyP4SrYUMf GvN7IvXEH0ip4PwMYK0Rt3WnEJBs7Q8= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1712125197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N6GmseYnDR4+V902wKBjRYx3D3EiRB4hYzZswSQsvkk=; b=bMfqNrGOWnuxDc4GG+1PPGwoyjQXTUFO63A1R9vGnsDa9slbdXSg7NyvsXb7/Pcbda1+VG i4c1upOuUH+3wulJEJ2YAAYgxm2MSvGPZd8SJPJJekXeSIWYnuZ2IcTeuTqawW6zkxDCWQ dGylmi6IpDceMHQ/2+CM1hylv7iTQP8= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: [PATCH] hugetlb: Convert alloc_buddy_hugetlb_folio to use a folio X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Wed, 3 Apr 2024 14:19:19 +0800 Cc: "Matthew Wilcox (Oracle)" , Andrew Morton , linux-mm@kvack.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240402200656.913841-1-willy@infradead.org> To: Oscar Salvador X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 176F6140008 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ttkikxo1tmptuu9n3hq3mg7d3ttsrbsg X-HE-Tag: 1712125198-902840 X-HE-Meta: U2FsdGVkX18H1AkMfxmLIoWdGYHhUOVUHUD8PfneCPBbwgZWHezDDrUZicdEhg9fJ4bqfWPwaPGy3JNvPFaWvKqs6rzrmWFhNzKzmz4uIlqMrHj9b8PeZWiXP6nfgZsu7M2AM35SNaqOz4rsLvEcNTfdrhmtQo6+IXwS9JMK5/+hM7xyTTty2VG8ggzl3ymEMT2qfy6bU8v/v/ni5B2lqybmv7VZ4NJCsXGScXmU+J/O6pm1jY2Ir1T8baYvFG4pZcG9ocdZZFoWV++O46rWnDn9yzxdL6yoef56dhRqxtlwPsefceluGXhHY37VNGjVkOMnSTGoJPxp0soxsf9bRO4TXURcj4K634pU0s9evSOpKb0y7Q0fiDZlk6GT6uE4tU/lxI/9uufK+W/zfHhfj/eROkoSctarhtGUMHmaPlhT0NfwjIDWKQ776VS/qLlPtfnyE30SyoB7zD0O9cMrt7H2gZKG4OQGxrW4aLuZYJfm19cRMNBmVcI58tW9H+BGCP2nyimrXVQTiAG8Elb6kyTqqSC1D/OcAw7JFBGjE6ihhcRG+x1QYyvklQbwc7Yh9qp7So+Aw3CB3GtQavuOQsaJRjp8PCh4jbLt7CrxG6Aokf2Xsauw8CiVYyxte5a4F3U+REXJzZDWz79IgJspICtwTQu7uiWUY/N9NaNvy5NvSikTqcinqMjuu2jxpZVz1TRXrhWM8v1lluvetSChcZEYv6Ow75kRKzZv435+EyCXwF2oYb/KbmQGw02FXytJwyKn0hXA+euc1vVXBPLpZv7mc4Lq7QS5XKgqEKmom13by8hXxbRcZ3M8l6renZdiRZkeLKxNpA3cSbSbcMHXPchXuklun/LfaSmr7kvXpn2KqiK3/tRMZg/HRebT3oVzWbIG2Qmqia0Ejs0V++HFEUVWaCdVkBdSq87UAfY3Z9nJaQvey+PtFqgO7vrevbV9v1T5cmlbg5v1tbddb2j SgVil543 NXQEZlP7CD5c0WDHel+tw0biDerHF+jLYlgjTUanPleR5CsoJ1BxMMCcsX5zoaT2SlJDxAIEfEU8cMV9POD1dPxd0YzCofpWdkl8kcn5fw0c6CtpG0nBf/iluSXCqtvQp1Azphc2WraFwXuhERYkLolKXkjoX1r2szUEJsQ+MbkQWQsycqRTNwKkY4Mq4ujxYPmHRrm5V+P2Q5mozGq/UpT0Lb7eekU34ZJSfGjCc6q2sQ5qd7QMm2LSRMyLGSYnNZFNL2mKrQPYE6qLi3zTwRrclwRpEtFoo0giiN6+/nCYXvjC+tPklm+WzaA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > On Apr 3, 2024, at 12:55, Oscar Salvador wrote: >=20 > On Tue, Apr 02, 2024 at 09:06:54PM +0100, Matthew Wilcox (Oracle) = wrote: >> While this function returned a folio, it was still using = __alloc_pages() >> and __free_pages(). Use __folio_alloc() and put_folio() instead. = This >> actually removes a call to compound_head(), but more importantly, it >> prepares us for the move to memdescs. >>=20 >> Signed-off-by: Matthew Wilcox (Oracle) >=20 > Reviewed-by: Oscar Salvador >=20 >> - page =3D __alloc_pages(gfp_mask, order, nid, nmask); >> + folio =3D __folio_alloc(gfp_mask, order, nid, nmask); >>=20 >> - /* Freeze head page */ >> - if (page && !page_ref_freeze(page, 1)) { >> - __free_pages(page, order); >> + if (folio && !folio_ref_freeze(folio, 1)) { >> + folio_put(folio); >=20 > This made me look again at the problem we had in the past with > speculative refcount vs hugetlb pages, and made me think whether there > are any more users trying to defeat speculative refcounts this way. > It was discussed some time ago that maybe all pages returned from the = buddy > allocator should have its refcount frozen, to avoid this. I think you mean this patch [1], right? With alloc_frozen_pages() introduced, we could get rid of the trick from HugeTLB code. [1] = https://lore.kernel.org/linux-mm/B4889CC0-5D36-44E2-B901-CDC5226995A2@orac= le.com/T/#m20457752e757cdafc99c7f5e6a3d8cbbb65fcd3e >=20 >=20 > --=20 > Oscar Salvador > SUSE Labs