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 D711DC48260 for ; Tue, 6 Feb 2024 01:01:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE7CE6B006E; Mon, 5 Feb 2024 20:01:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D98196B0071; Mon, 5 Feb 2024 20:01:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5EDC6B0072; Mon, 5 Feb 2024 20:01:22 -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 B642A6B006E for ; Mon, 5 Feb 2024 20:01:22 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8193E1401F4 for ; Tue, 6 Feb 2024 01:01:22 +0000 (UTC) X-FDA: 81759575604.16.7AEAE8C Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by imf04.hostedemail.com (Postfix) with ESMTP id 5C46740013 for ; Tue, 6 Feb 2024 01:01:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=dV7hNEBf; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf04.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.133 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707181280; a=rsa-sha256; cv=none; b=qyAzkmQ/TXl/dk8lNzZfyWRzD6rLUKv2P8XuUFUq8v0z6Rnef+hmB5zSbZw6WE2NTkg0rO sO2gZPqCiFkLcqJPBv+GXRZLhjfHJ5V1/5D1eUetkC80SkHOqJPSlEFlaCl/DxTXIRVpLE xAmZEhr4wav7XbIFbeAEVfwcYJFqGr8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=dV7hNEBf; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf04.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.133 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=1707181280; 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=7c1tboIXd34qXTIIwjvuY/4rNTG1OWDCX7nIPdrejzY=; b=CaxCj+5+9gySP6I3eyq17ynq++WzlhaGOiWm95YWgKWJgruH1pcbRANHyNfqwErFtLSmlm sMySd0Js/X1A0nNK+E+RQZrq6WnmG9LGlcnEXT+urL6RK+GStZ0/zOh2Ax90MPHwvx/iag rK2fuxgZfs7kl8ANdS1WiyfuMB6RdMo= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1707181276; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=7c1tboIXd34qXTIIwjvuY/4rNTG1OWDCX7nIPdrejzY=; b=dV7hNEBf0zcL8djzUR0M7K7DmP1N10ngixbmV8JN0TalMJDxEF1S40Fp1tBfMErfn0HK4OTNfDrX/C7q3B3ePkmxK1DxKRV7zrhhBW1uariQC9lK3hv1yR4arCLYkaaLAnVZ8kld2Ix3PLeID7IxYtXfH7HlLBbaCk3ZJQZKCN0= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046050;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0W0Bns7B_1707181273; Received: from 30.97.56.40(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W0Bns7B_1707181273) by smtp.aliyun-inc.com; Tue, 06 Feb 2024 09:01:14 +0800 Message-ID: <1ecddd3f-957f-4dad-90e3-cb820bbe36ec@linux.alibaba.com> Date: Tue, 6 Feb 2024 09:01:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm: hugetlb: improve the handling of hugetlb allocation failure for 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: <23814ccce5dd3cd30fd67aa692fd0bf3514b0166.1707137359.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5C46740013 X-Stat-Signature: c969psom5w3rti3bhgrdz9o15r885pbr X-HE-Tag: 1707181278-266505 X-HE-Meta: U2FsdGVkX1+vsi/RtLgB6I4CCwrscfEhwtW1k73BKrDFSGK0j/Vj6ADae0Fb2WHNgZlXR418I5gMzmrqoo28Bb9Gde9TEyQO0NAxynemaMKUde1W1exrU3A1YLg8MD20eRhU84J6+ddNijLF5vsmxhcg2f4/U5qJgrG1+XTepcu+VJi+c1z4HuIU9bANhfoHGeOSt7Difo1IKrUHR0uwPW826QBCrVMAfemywgJK4el88u0IXQrgJgBJDCEpCL9B2qPssTF3wrsvCF8dXcdft8pCtjjQC/olj50wu7WYURYBSCamkwI4Zco09tf+s0ZpOL83lUKb5qrVpqbDk5nTq4ZZI9fACpdBgSftxuU3ifUWC0DmMP41h6RC3dZbwAJoOpWiAbPN0q4rjYyowsINqp7rz/7UGzFRPmY+cN/HqPIBytn0dkOq2UvQO6cE/nmugggmSZIeQkEBcwMPb2DEQZWjsFPYyPusiMlVBAzBl2aIBCBCt+eaR/RZBB4stp3zY8cQCZpj4vBFFGbRL+r0ABeULLMZoqiI95RGcvvdy+2vQoq+6KMz6oGgy+WaHBGr9jG2Ra3DIxM1s1hV/amMGBgjgg/1NDZV9e30BIbEv4jyRoGSjtqovHAu6wNDTYfpHp7tDmY9lEqpwSpw3PewmZ945YZMvQ81Psd2sspz9EiwXg7tdCohPYa9qR5m4OBJRnQUWltQ0YMHCzDMIZfLErE4fa6M2Ny+tMroRImKOToJYHYnx0FdkkycP9QXDG4mUMek90p5fx/VBipxMVqh8Zgbi8bys3Wh0RuAzr5uk0Ck84C4JAwFF9+nlYyGNaCmG2SqKjR4qij+rJPq48eJ9sVpVPz/Qoiv2lIVrGBTizjnks+anGauW6eWzRbNBODqQ5g5KRNmqcIBW1LnkHAtxwBIi8x1jrAw0ZoYg+v6bKXZMs/uFFZQJdLm9fi2yWQpH0IYYRfx4w5kT2Me+Yv E48fd6F5 iAoq2pGB/J9alIxh6zrBPHBpvgLCiRb4VV8OjfRnfoeZd4kjLxiqiW6DbgudF9G1NJZriP0Y8rEJArgMFvfJpxWxcXDXdAH2ypDW0Oi6JkSyHaNkM9YMPfTpRfzu/EWcLv5SS7o+jy+uROL5monC69tbtIMmQWE74ruTCZjULOqhwkiXoZHVrqk17sy5IUiQtnsC7UjzJUm0TqPRART6RC3+gj3oROK8/oxVlToAhw+ea36yqJ6nolJceRpIYM61ws1oZejxe8x/sK1A4woUN9rTp7Y0nLw4yupCRrskidoMhTvPRZ8o28Z/xmg== 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 10:47 PM, Michal Hocko wrote: > On Mon 05-02-24 20:50:51, 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. Moreover, >> moving the allocation into the free hugetlb handling branch. > > The changelog is a bit hard for me to understand. What about the > following instead? > alloc_and_dissolve_hugetlb_folio preallocates a new huge page 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. > > 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. > > The patch is more of a cleanup than an actual fix to an existing > problem. There are no known reports about pre-mature failures. Looks better. Thanks. >> @@ -3075,6 +3063,24 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, >> cond_resched(); >> goto retry; >> } else { >> + if (!new_folio) { >> + spin_unlock_irq(&hugetlb_lock); >> + /* >> + * Before dissolving the free hugetlb, 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. >> + */ > > This comment is not really needed anymore IMHO. Acked. > >> + 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 >