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 4E77FC48297 for ; Wed, 7 Feb 2024 02:25:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA01A6B0082; Tue, 6 Feb 2024 21:25:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D28BF6B0083; Tue, 6 Feb 2024 21:25:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC97A6B0085; Tue, 6 Feb 2024 21:25:39 -0500 (EST) 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 A897B6B0082 for ; Tue, 6 Feb 2024 21:25:39 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6A8DB805E0 for ; Wed, 7 Feb 2024 02:25:39 +0000 (UTC) X-FDA: 81763416798.07.6680772 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) by imf18.hostedemail.com (Postfix) with ESMTP id 69DE21C0002 for ; Wed, 7 Feb 2024 02:25:37 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=PvQ5YOH0; spf=pass (imf18.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707272737; 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=KxDGt9b3bgYXiw9ZtkUhOb/RH81efkpcL0KqwcN75VA=; b=4R5kU4hRZLApK5Mujgh8CKIzJgaKON4nn11HdWG1UcQLSHElEUUNIsE3sP52djbN/fumBI /pJOkY8CpbosKWvQaQEsX+bjWKnbmQvI5scJ+oSfwHXTyXAMjApLlxcf2BmRgNrKiIlAIN qyZaA4VxUXo6HQAkhiSM2gQuSsqLqXI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707272737; a=rsa-sha256; cv=none; b=M4TQnjt3vEfe6ReHVG8GRGIflAql451KOSNaNVT3ru3UzAFVsJisXP0iiVXn8C7aBPIJm3 eMpNFlozGw2ybfOPNgNQWeue5dxaWQeyg0wQ2ftrvoESYp6gRMgZlEUUbq5KzB2v+4MTYT AHjj79CbDZUX2cikeadHCnk2Q643qfE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=PvQ5YOH0; spf=pass (imf18.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707272735; 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=KxDGt9b3bgYXiw9ZtkUhOb/RH81efkpcL0KqwcN75VA=; b=PvQ5YOH00zOroTBNYKsZS52hOf+6xeqTmhSZoJIDwWQuhwYD2kGq/THf2t9yMELPeqFqwa hSMc7XmhwbuGoUTbDCkjBE0rEfqcv24cUEsg0/x2Upsy9PoBTc4Wd7KAV8gn8VO3hkvqfH o+26BJbbfBmzRv2GjgeVeFuLfvrHUoc= Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song Mime-Version: 1.0 Subject: Re: [PATCH v3] mm: hugetlb: improve the handling of hugetlb allocation failure for freed or in-use hugetlb Date: Wed, 7 Feb 2024 10:24:52 +0800 Message-Id: References: <62890fd60b1ecd5bf1cdc476c973f60fe37aa0cb.1707181934.git.baolin.wang@linux.alibaba.com> Cc: akpm@linux-foundation.org, osalvador@suse.de, david@redhat.com, mhocko@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org In-Reply-To: <62890fd60b1ecd5bf1cdc476c973f60fe37aa0cb.1707181934.git.baolin.wang@linux.alibaba.com> To: Baolin Wang X-Migadu-Flow: FLOW_OUT X-Stat-Signature: cfwekfhbd7qtru5ri9zwecs7bzzibd3k X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 69DE21C0002 X-Rspam-User: X-HE-Tag: 1707272737-524565 X-HE-Meta: U2FsdGVkX1/toTSuKascpqABFGQepGmfFplAlygYmcqFMGIljCWyyd2Q/EmjHy9LX7r4OoUqD8fxf5Wnfy7rulQk7MPjuK//iPGXE1l6roT/UakKNCMNVR8udW2i5z8hLeyUQO/UzoaBbEWAl0AhbJAn3EKbrUqcqa9rcqGojGXAAG29Og3oizuzG1C2Uey/6OZGlF9g86JCL5LsqVNGHv57TD5gVJK91w5eugA9DR/7JMHjr7VlS6zfyEv6JIPrxJ8IoBM/B8pqEG0QT0W3w02WFKgJrkPpbd3+F82Ad57Q0D973VYiiHHIitI7uKA8jWDwTvS5e0qs1wzgj5b4hvS+1ZBn3pHfugjIXwc2bJVRsBbkSQgqv0Jb26Jzp5R/lYWPV5rarG2ej7RhPxpk8HmJnfYltUhlGfDsbCJGhZ+AN5Pg/eTBOVxiFSkLfJu8r6wifmDwMmXXENb96c8py6W90T/hDtdtgXA1ek9HxMyO9LilXg9dLCwYIG/tuoGjdF9ba2H9I+SrkxMzPw9b4lhUruLMSy1GEFuU3UDTB7AbCRUINmV7AbDYfCqKekEau2bM/+a1EDDn4Hm8YRviIMpaybOvHdhCfSat+CQw76miU9weRrJQ6wkT/RXSRAtRhrM5awSaAndonTqAb2mkRka2ZO1fC6cOkiR7Y1THuqBDatlNlq3jsDts06LTnUA6X6e+uM2snq20zp7ZiezqD1ZsQtP1kqn4isB9d9+w1QEE6evYRkjCFSwMqjic/Y3gM1G2/2KNFX3EIsisjnFyYqtNeaHSuIT3KL+Uap4EWLFVrXH+KnVTBhvNLjixNlGwumCZh6vPAX88kShnChHuBwSiQwYk/LALQxSKXwqkCgoHQrKcLqjNVMhHbjivhzW+1yH+QGwMH24hHN6z1ireCzJ58EwPxJv08mmt9NM21uI+fUCO9nLpMf2sINI7DtcxIKPAFLwGab7gZrvKvSQ 30+rKZQw WK2ywiAFO/JYS1B+BLmUX3MnG+JOrr4bUt9zyYa+RGODCogv+Ehc+UBKLmv9ZgZ8nfTrPFVVs582cT9qCLmTHQaI24rQBMuANN+VpOXj/2Z04qk8XEGqhhpnFI8ts4G8QXGuq7K9izb1gJDKMcFvCpPaFMrB2yqeuGBHU+/XblR6OA4s= 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 Feb 6, 2024, at 11:08, Baolin Wang wrot= e: >=20 > =EF=BB=BFalloc_and_dissolve_hugetlb_folio() preallocates a new hugetlb pag= e before > it takes hugetlb_lock. In 3 out of 4 cases the page is not really used and= > therefore the newly allocated page is just freed right away. This is > wasteful and it might cause pre-mature failures in those cases. >=20 > Address that by moving the allocation down to the only case (hugetlb > page is really in the free pages pool). We need to drop hugetlb_lock > to do so and therefore need to recheck the page state after regaining > it. >=20 > The patch is more of a cleanup than an actual fix to an existing > problem. There are no known reports about pre-mature failures. >=20 > Signed-off-by: Baolin Wang Reviewed-by: Muchun Song Thanks > --- > Changes from v2=EF=BC=9B > - Update the commit message suggested by Michal. > - Remove unnecessary comments. > Changes from v1: > - Update the suject line per Muchun. > - Move the allocation into the free hugetlb handling branch per Michal. > --- > mm/hugetlb.c | 32 ++++++++++++++++---------------- > 1 file changed, 16 insertions(+), 16 deletions(-) >=20 > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 9d996fe4ecd9..a05507a2143f 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -3031,21 +3031,9 @@ static int alloc_and_dissolve_hugetlb_folio(struct h= state *h, > { > gfp_t gfp_mask =3D htlb_alloc_mask(h) | __GFP_THISNODE; > int nid =3D folio_nid(old_folio); > - struct folio *new_folio; > + struct folio *new_folio =3D NULL; > int ret =3D 0; >=20 > - /* > - * Before dissolving the folio, we need to allocate a new one for the= > - * pool to remain stable. Here, we allocate the folio and 'prep' it > - * by doing everything but actually updating counters and adding to > - * the pool. This simplifies and let us do most of the processing > - * under the lock. > - */ > - new_folio =3D alloc_buddy_hugetlb_folio(h, gfp_mask, nid, NULL, NULL)= ; > - if (!new_folio) > - return -ENOMEM; > - __prep_new_hugetlb_folio(h, new_folio); > - > retry: > spin_lock_irq(&hugetlb_lock); > if (!folio_test_hugetlb(old_folio)) { > @@ -3075,6 +3063,16 @@ static int alloc_and_dissolve_hugetlb_folio(struct h= state *h, > cond_resched(); > goto retry; > } else { > + if (!new_folio) { > + spin_unlock_irq(&hugetlb_lock); > + new_folio =3D alloc_buddy_hugetlb_folio(h, gfp_mask, nid, > + NULL, NULL); > + if (!new_folio) > + return -ENOMEM; > + __prep_new_hugetlb_folio(h, new_folio); > + goto retry; > + } > + > /* > * Ok, old_folio is still a genuine free hugepage. Remove it from > * the freelist and decrease the counters. These will be > @@ -3102,9 +3100,11 @@ static int alloc_and_dissolve_hugetlb_folio(struct h= state *h, >=20 > free_new: > spin_unlock_irq(&hugetlb_lock); > - /* Folio has a zero ref count, but needs a ref to be freed */ > - folio_ref_unfreeze(new_folio, 1); > - update_and_free_hugetlb_folio(h, new_folio, false); > + if (new_folio) { > + /* Folio has a zero ref count, but needs a ref to be freed */ > + folio_ref_unfreeze(new_folio, 1); > + update_and_free_hugetlb_folio(h, new_folio, false); > + } >=20 > return ret; > } > --=20 > 2.39.3 >=20