From nobody Mon Jun 22 22:25:02 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 244DEC433EF for ; Wed, 16 Mar 2022 03:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353394AbiCPDRw (ORCPT ); Tue, 15 Mar 2022 23:17:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234584AbiCPDRt (ORCPT ); Tue, 15 Mar 2022 23:17:49 -0400 Received: from spam.unicloud.com (mx.unispc.com [220.194.70.58]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CED55E15C for ; Tue, 15 Mar 2022 20:16:35 -0700 (PDT) Received: from eage.unicloud.com ([220.194.70.35]) by spam.unicloud.com with ESMTP id 22G3GIB8054293; Wed, 16 Mar 2022 11:16:19 +0800 (GMT-8) (envelope-from luofei@unicloud.com) Received: from localhost.localdomain (10.10.1.7) by zgys-ex-mb09.Unicloud.com (10.10.0.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.17; Wed, 16 Mar 2022 11:16:18 +0800 From: luofei To: , CC: , , luofei Subject: [PATCH v2] hugetlb: Fix comments about avoiding atomic allocation of vmemmap pages Date: Tue, 15 Mar 2022 23:16:02 -0400 Message-ID: <20220316031602.377452-1-luofei@unicloud.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.10.1.7] X-ClientProxiedBy: zgys-ex-mb11.Unicloud.com (10.10.0.28) To zgys-ex-mb09.Unicloud.com (10.10.0.24) X-DNSRBL: X-MAIL: spam.unicloud.com 22G3GIB8054293 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Since there is no longer an atomic allocation of vmemmap pages, but a fixed flag(GFP_KERNEL | __GFP_NORETRY | __GFP_THISNODE) is used. The description of atomicity here is some what inappropriate. And the atomic parameter naming of update_and_free_page() may be misleading, add a comment here. Signed-off-by: luofei Reviewed-by: Muchun Song --- mm/hugetlb.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index f8ca7cca3c1a..fbf598bbc4e3 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1569,10 +1569,12 @@ static void __update_and_free_page(struct hstate *h= , struct page *page) } =20 /* - * As update_and_free_page() can be called under any context, so we cannot - * use GFP_KERNEL to allocate vmemmap pages. However, we can defer the - * actual freeing in a workqueue to prevent from using GFP_ATOMIC to alloc= ate - * the vmemmap pages. + * Freeing hugetlb pages in done in update_and_free_page(). When freeing + * a hugetlb page, vmemmap pages may need to be allocated. The routine + * alloc_huge_page_vmemmap() can possibly sleep as it uses GFP_KERNEL. + * However, update_and_free_page() can be called under any context. To + * avoid the possibility of sleeping in a context where sleeping is not + * allowed, defer the actual freeing in a workqueue where sleeping is allo= wed. * * free_hpage_workfn() locklessly retrieves the linked list of pages to be * freed and frees them one-by-one. As the page->mapping pointer is going @@ -1616,6 +1618,10 @@ static inline void flush_free_hpage_work(struct hsta= te *h) flush_work(&free_hpage_work); } =20 +/* + * atomic =3D=3D true indicates called from a context where sleeping is + * not allowed. + */ static void update_and_free_page(struct hstate *h, struct page *page, bool atomic) { @@ -1625,7 +1631,8 @@ static void update_and_free_page(struct hstate *h, st= ruct page *page, } =20 /* - * Defer freeing to avoid using GFP_ATOMIC to allocate vmemmap pages. + * Defer freeing to avoid possible sleeping when allocating + * vmemmap pages. * * Only call schedule_work() if hpage_freelist is previously * empty. Otherwise, schedule_work() had been called but the workfn --=20 2.27.0