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 AAF32C4828D for ; Mon, 5 Feb 2024 12:38:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 442F46B009F; Mon, 5 Feb 2024 07:38:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F2FD6B00A0; Mon, 5 Feb 2024 07:38:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BA5D6B00A1; Mon, 5 Feb 2024 07:38:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 176BC6B009F for ; Mon, 5 Feb 2024 07:38:49 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D96621201DF for ; Mon, 5 Feb 2024 12:38:48 +0000 (UTC) X-FDA: 81757704336.28.63844F6 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf10.hostedemail.com (Postfix) with ESMTP id 5561FC000E for ; Mon, 5 Feb 2024 12:38:44 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="C/Mso+Ar"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf10.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707136727; 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=EPrTp2HaSci14lwoV1Q3t2am9bD2lGmQe7hOOG3fJgk=; b=3/OBM7A/hD6USPXfBMISJfi6y3+1f739H7AANg1u/pSyqmGksLwu4WRIX4PvTo3roXvRkP pupIXkmBTWmA2k62k7xrtXFoO1x1eyUV5rmlOUh+NYxRxOlebPlobwDhVmfGKO9P6zHz8N Xf3aMqndfDkIPeGeRw1TG3MwehhAHcw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="C/Mso+Ar"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf10.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707136727; a=rsa-sha256; cv=none; b=JeJk2evfQpPWX3aSfRPRQd9uH0peTRZVuClfS9RhHywHFeCx+wpkJ10GRoeTLr5unZsBh2 LnIMTpfLfkdU8e2rg6KZXNdHQego998d2K/+oF+I8C6N+pgssWiqgjNJBOGXeG0LHRk9tq OV1S5S+iFHF7LorN46/9xvrLIAYCKdQ= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1707136720; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=EPrTp2HaSci14lwoV1Q3t2am9bD2lGmQe7hOOG3fJgk=; b=C/Mso+Ar5rA3ddRqyakX7X+iNkgtpf0PIjXj/NlCAqPc3bZwxFgA5dZFPjVPHNuqM2B23cL9mQud2XYkVzLE79uxUcnHEjLEHlw+Bq9pYbwbaYtSpjwpHf0oF5zne2Blcbv7Rrv1XneXeeou7o/gMtn6ozs09wuA5+J8LZIyw30= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R981e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045168;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0W0AY-Un_1707136718; Received: from 192.168.0.105(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W0AY-Un_1707136718) by smtp.aliyun-inc.com; Mon, 05 Feb 2024 20:38:39 +0800 Message-ID: <88ff7f59-654c-4313-b2db-a926b4ca86b9@linux.alibaba.com> Date: Mon, 5 Feb 2024 20:38:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: hugetlb: fix hugetlb allocation failure when handling freed or in-use hugetlb To: Michal Hocko Cc: akpm@linux-foundation.org, muchun.song@linux.dev, osalvador@suse.de, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5561FC000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 19gsgpz1upgtiefciy8xab5cruresz5f X-HE-Tag: 1707136724-794899 X-HE-Meta: U2FsdGVkX18Nyi40KdCFHiYtyX2xtEtezNJIJScAyl8Sd0dp+nkLcW6kl7kCmh7mYaDW1HOI8JkF5ALbhBaNMSD//7nRoJe0Sayr3NkMBVXRH1xHgSgeGwacarlOAmXmGTKOWES+q50sTdbMdf0O03T/eSmr6LBHarTOUyQYsa4b39Jsk8NV8FiObEZYZivRx0pT8MvPNDO1iivmmdNtVB6jQLnU9rhnuS+OHLtJ/1J3HVG/6YwxFOyqQTLLX+PGuG3GmciH0Gqr7vwC0kLk2V1pWm3CkcHBVOPGINQJXhJCCvn9I4kNuPNvfOneOfb+RfkKyq918mI7LSEm4ZMfnptp8nH9xZ8Qayh+Z25nhR8ufMU+HxhNcMTlKUtad+P5pmBFG4sH6u+VEjulnn6cs72ZY093iqEZIKihYM9MmkhUfBuqbzt6F5JQdAlDGbSf++Qj47d1RY1rej565N2RAkj5L+M9E9b3KMr1xxG05maEekAiyJBiYAs45dqiTbb20C/0fLbwOaiyUk/ER3TLA9Zn2wZq5dXajonkz9c643ycYC8RogLEf6dmNvLQgEKHG02C4mm/6noKBfk+TU0TNuWq8lUq1jf/+Sm1EkN6pa2kk9AZZsG/MX+Auag0FoC8qdxH1C6qQJP0fZZLJrRoaZ/GMkj5+gEYOMcjit+IXYKZ+EiK/rXwm/r1Oa7KS+XdectvKE6U/A6ljP1Bo2Q+v5rBPJKWvZswcXXKXonZJBPHKdKw+AY2b2lZw/IukNpyrq3ngrMUyyHerY4EmrygXdb1CUozs3PZGX7GclpzzmOfFLqnhlPZ5XXIaVj7xa1ZcJdABhoW6WsvaDL4DWNVNmgzKM3UGJWEdpwlUP0ppQ5WMDo5vX3OaqQM6FM5Ajtmno7y6DABzlswv5bOmXm0adM3s0Nw3tmFF5hbs/45PLTYsneJRsrJT96wwpROdxPlAKNA3qbJCUOd8B2hh73 0o565rIT jTP+oEmKUWaghSU9jtkkY0jxS9778jPSh0BqK4vyjXdQhWuLU0MUu86aoG7H9jqgonk5oOgzcGPMJQ6zSw69+wl2aXyFUaJlllIA1f2brGuxxVOLGkhoXKfXsDMWNun2XBD8zjX30eEDoYkoya6ul/iKbZSlfcd1e7g1IW3xYq69OZrazs389ulUc3+IoxpwhmYMBlCLHtZtRJOXPUD/iWEFb8TSW3bIR4yyLrtDz9ehEqOA= 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 2/5/2024 5:31 PM, Michal Hocko wrote: > On Mon 05-02-24 11:54:17, Baolin Wang wrote: >> When handling the freed hugetlb or in-use hugetlb, we should ignore the >> failure of alloc_buddy_hugetlb_folio() to dissolve the old hugetlb successfully, >> since we did not use the new allocated hugetlb in this 2 cases. >> >> Signed-off-by: Baolin Wang >> --- >> mm/hugetlb.c | 18 ++++++++++++------ >> 1 file changed, 12 insertions(+), 6 deletions(-) >> >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 9d996fe4ecd9..212ab331d355 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -3042,9 +3042,8 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, >> * under the lock. >> */ >> new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid, NULL, NULL); >> - if (!new_folio) >> - return -ENOMEM; >> - __prep_new_hugetlb_folio(h, new_folio); >> + if (new_folio) >> + __prep_new_hugetlb_folio(h, new_folio); > > Is there any reason why you haven't moved the allocation to the only > branch that actually needs it? I know that we hold hugetlb lock but you Nope, just did a simple patch to ignore the allocation failure. > could have easily dropped the lock, allocate a page and then goto retry. > This would actually save an allocation. Yes, will do. Thanks. > Something like this: > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index ed1581b670d4..db5f72b94422 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -3029,21 +3029,9 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, > { > gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE; > int nid = folio_nid(old_folio); > - struct folio *new_folio; > + struct folio *new_folio = NULL; > int ret = 0; > > - /* > - * 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 = 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)) { > @@ -3073,6 +3061,15 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, > cond_resched(); > goto retry; > } else { > + > + if (!new_folio) { > + spin_unlock_irq(&hugetlb_lock); > + new_folio = 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 > @@ -3100,9 +3097,11 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, > > 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); > + } > > return ret; > }