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 01120EB64DA for ; Wed, 12 Jul 2023 08:04:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CD038E0002; Wed, 12 Jul 2023 04:04:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87CB18E0001; Wed, 12 Jul 2023 04:04:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71DBA8E0002; Wed, 12 Jul 2023 04:04:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 601538E0001 for ; Wed, 12 Jul 2023 04:04:31 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 306B81C7C0B for ; Wed, 12 Jul 2023 08:04:31 +0000 (UTC) X-FDA: 81002222742.01.7CEA209 Received: from out-30.mta1.migadu.com (out-30.mta1.migadu.com [95.215.58.30]) by imf11.hostedemail.com (Postfix) with ESMTP id 2F8234000F for ; Wed, 12 Jul 2023 08:04:27 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=h+DR9B2F; spf=pass (imf11.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.30 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=1689149068; 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=1kQGtHc+N0kBzheMdTFEuRcExKmasAznpDZbENi8pLk=; b=XisGDMv6n2q2D3PNPMDyWxkD7Yw3Bx1a3gGtnxpqCoshoBgAPC2nq6b7orpNTyB790P/rW v7hccFGjATds08Kt5MB7nHd6Q9jelZhAAtorj0N4ZaW+EJ1OV8vuTRUcQ2uD+hut7O1BOg 4szRS42G2Z7JMBk48MAKDhr0iZ8OZIM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689149068; a=rsa-sha256; cv=none; b=jSmi5CpkFfLwwiKYQnFMH7I4KzGaJ+RTRpzTSlDxyM/92dSu9zYvrQOfGWCBKvnNSXaSiJ Pa8D6GiWMtIcJ1Y+R+3bU7dEji34nKROdEVHl9SufBM5E9iSO2P5kX18LOpsGDYhoBsrI3 hB94AypGN8DTZzT2JSFSUkqE4VbEaQ4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=h+DR9B2F; spf=pass (imf11.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.30 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1689149066; 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=1kQGtHc+N0kBzheMdTFEuRcExKmasAznpDZbENi8pLk=; b=h+DR9B2FISyzDGCFrq/K/NU6zpYWWVYhJgPEvBQCkSLqHUchXRPV5dvh81F5Hdkp6mVqoq mP/bwmQWfPEHqkySzty5kKM8gG5qRRYhgkXuqh74BgJf63KBhO2lKDeijzxBP6b0gIEDaK KWikBffTqmCQxjje3bOwzeZUP4af+Ns= MIME-Version: 1.0 Subject: Re: [PATCH 1/2] hugetlb: Do not clear hugetlb dtor until allocating vmemmap X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20230711220942.43706-2-mike.kravetz@oracle.com> Date: Wed, 12 Jul 2023 16:03:42 +0800 Cc: Linux Memory Management List , LKML , Jiaqi Yan , Naoya Horiguchi , Muchun Song , Miaohe Lin , Axel Rasmussen , James Houghton , Michal Hocko , Andrew Morton , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <4469DCBD-59B4-41F2-A097-E5F01DD9E967@linux.dev> References: <20230711220942.43706-1-mike.kravetz@oracle.com> <20230711220942.43706-2-mike.kravetz@oracle.com> To: Mike Kravetz X-Migadu-Flow: FLOW_OUT X-Stat-Signature: rrt7j5ra3n3shukrc89bnu41k886ja4j X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2F8234000F X-Rspam-User: X-HE-Tag: 1689149067-823538 X-HE-Meta: U2FsdGVkX1+O4Q3u9Rdc0cu5nnj50ZuL3kHGtQSrRQ9SMOoe1spsk4h9FmE3pYymJcgIKaLud7EyM4/CdoP7MYkl8Q8+iHnnMh8hcOxoLEsCxFIT5oy8F0RG507ZbobK5Go95zAMNj3vLhC/HZmwVGWztQX/lLf/K0AyNoDcXw5gOxlouVlrlH3ANVu61PXwN1i7ruKqvz26Cyox3Zn+8qleublvpkZtRAwnUl/WHQWR3gasw4pyy6wsX7hyB7foph/6V6RRi51B60Vt9u6wpGA3B/NQk6mDU5JvHa/nRpKncP8zkk8K2rEcbB5wljKywDUaF0NfqPw/YiLkri7wZXAeYz1VIlJtSt708jDS2d1aG7gDhdcVqa79tQWmoUhy+5ZTZ0Tvr9Tnmpjv9QfFad1fNkheJ2weMTTICDUzNim5j26xptLVzbYoSdqSga2Dzwl/vsjVmK3ONGw017usG4K4S0t0lkH4Xxvbn0AIQPshM0evBd7W48STPZhajZmNlogdpWIr/4xP9kD2qXrsxVibHzoNl2mYKOv3WLS3Nc7H5B3VFTPuGhkl+LGKsOfkar7YndephHr4frls1iT2VZS0tLuXG9ZiVIdVlKHUan1Yf4D0pKbuYuJcr3qykjEyC/tj/VLvI9ma5fBqtnDxM0DBJqTvbOS2XJIMvwTmfBdms3Ous4DHUFWlIW5I9JzcVgOGVpVdCX2u1I4E+ihn8ITeHlwoRceS4UVTEPWSk5Zf1AzxLX0JrwDxQlzbfurqnJ3kI/ZoXj+9a1TWiWThgYrr6t6FgEeWYMbGS2oMN8nMBWUapMWQKkO0uoT6TztIdK/HyKz2LuFFTPxeJ4QSeEc6SoTc6RVSECT/uqHmgFWqq2j2tozYOkhHaORMO9dvmqcKAo7wPKykAF+bfrJC069FTWqbdzLkMXqgZ0HgqEL56+GMtkr9rqq7y8cuIlHNJEzoLHFiM0NTMwG6Dn+ 7HPHJf7v u6kQs1DyJRxbJr5lL79XlUhhoGoD69uB+cxAFyA9FeIj42B/FDj+Psh1QADzg1xuZNsaiGNTX5sbLhSimivr4BTQoWAGll55QZOzRZYQYMzm9rVDjls1zy1zCI/cuxkNh/8FO4Wv7XET8LZWCaxYhlpc8Ay5yyzB1AfvPxtSwuImqfgGRK17FDvI0h06yF6CK5RI3 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: > On Jul 12, 2023, at 06:09, Mike Kravetz = wrote: >=20 > Freeing a hugetlb page and releasing base pages back to the underlying > allocator such as buddy or cma is performed in two steps: > - remove_hugetlb_folio() is called to remove the folio from hugetlb > lists, get a ref on the page and remove hugetlb destructor. This > all must be done under the hugetlb lock. After this call, the page > can be treated as a normal compound page or a collection of base > size pages. > - update_and_free_hugetlb_folio() is called to allocate vmemmap if > needed and the free routine of the underlying allocator is called > on the resulting page. We can not hold the hugetlb lock here. >=20 > One issue with this scheme is that a memory error could occur between > these two steps. In this case, the memory error handling code treats > the old hugetlb page as a normal compound page or collection of base > pages. It will then try to SetPageHWPoison(page) on the page with an > error. If the page with error is a tail page without vmemmap, a write > error will occur when trying to set the flag. >=20 > Address this issue by modifying remove_hugetlb_folio() and > update_and_free_hugetlb_folio() such that the hugetlb destructor is = not > cleared until after allocating vmemmap. Since clearing the destructor > requires holding the hugetlb lock, the clearing is done in > remove_hugetlb_folio() if the vmemmap is present. This saves a > lock/unlock cycle. Otherwise, destructor is cleared in > update_and_free_hugetlb_folio() after allocating vmemmap. >=20 > Note that this will leave hugetlb pages in a state where they are = marked > free (by hugetlb specific page flag) and have a ref count. This is = not > a normal state. The only code that would notice is the memory error > code, and it is set up to retry in such a case. >=20 > A subsequent patch will create a routine to do bulk processing of > vmemmap allocation. This will eliminate a lock/unlock cycle for each > hugetlb page in the case where we are freeing a large number of pages. >=20 > Fixes: ad2fa3717b74 ("mm: hugetlb: alloc the vmemmap pages associated = with each HugeTLB page") > Cc: > Signed-off-by: Mike Kravetz Hi Mike, I have seen an issue proposed by Jiaqi Yan in [1]. I didn't see any resolution for it. Am I missing something with this fix? [1] = https://lore.kernel.org/linux-mm/CACw3F53iPiLrJt4pyaX2aaZ5BVg9tj8x_k6-v7=3D= 9Xn1nrh=3DUCw@mail.gmail.com/ Thanks.=