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 B6417C433EF for ; Tue, 15 Mar 2022 13:31:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B97E8D0002; Tue, 15 Mar 2022 09:31:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03D478D0001; Tue, 15 Mar 2022 09:31:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD0778D0002; Tue, 15 Mar 2022 09:31:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id C98EF8D0001 for ; Tue, 15 Mar 2022 09:31:18 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 828AC181C4420 for ; Tue, 15 Mar 2022 13:31:18 +0000 (UTC) X-FDA: 79246707036.31.71163AD Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf08.hostedemail.com (Postfix) with ESMTP id 9CC9A160005 for ; Tue, 15 Mar 2022 13:31:17 +0000 (UTC) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-2dbd97f9bfcso201363747b3.9 for ; Tue, 15 Mar 2022 06:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OtmsmQ/2gw1Y/pirhEjotykkKVj7SlHkh+ESAiuT6AQ=; b=iS+6HlPy0XVq/lxHBqvNeCdXtO/YQeIIOogSh7EkTGKqgE4SZ7DW9s0k2ehFjIC/G7 dYht0cLbK/1YmZhCYwBXxR84bcMJH2FtxUwHFGq6q3KQv3nfNjIiglPXH3Q/qHpR3DYN KrgRAwgBIbeJDXK/e9NljAehsKpHrq72xxZafuD043QmlhWRs+A1THQX0yh50vjddRSB EnjOlXcpn8ypQVskckivErvkMA8VZtI7/JOzfsxCX38IoY2mb/1qPGr5VXAapzUoP4vW 9LvK1lY3eZutiXhO3d+eQo5/8zLnny9+96ZQxObs2uAp7RV9IVatYWpPflLypxvISnLv 5Uaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OtmsmQ/2gw1Y/pirhEjotykkKVj7SlHkh+ESAiuT6AQ=; b=K5xwmDe+n2g5v5bbgcQoVIfcsDrIBzE7xEqG18g+G3XSgDHCbM9wTU3cHq8PuSE5ET lKjkz/6h5LhZCMEkQcvMvMZ9SckLBw+6CelboZnjYVniRscBGMtdanXg0Mrw0oARDeG0 KqkpASFDgNCcwQxBsgHWzYBCnBLuRNeFmevl2TSfqULDC5AkSWNv6AIuj2+WXVehgn0B nGNfi+WOf8XjHdXJB+AHInTIuvXkWPFKhtKEOL+lukW9/79ONSM4t4fkVM0A045rvFLr NQRLrWlZkyV+a4szpoPsU+lcef24zaPjNKR3ZllIdfH6GyjScsgi/8tEbWgmV+Ek2Mnv chEw== X-Gm-Message-State: AOAM533cFLw0goVU/SI4aU+hIBsHU1lsbcNBVYhaoqdg7Pllefn8l10p pTkCdsuaAKKFSxsq0LqYR8dyjyeOwJxlQJPumMlEGw== X-Google-Smtp-Source: ABdhPJx3VldPxFAeybLShowpLLsYaEK8Fd0JU4RVR5/Jh2rjAXJprvQ6wb29fZHBTFX9bjLmeAdtEZPNX6J+pcdsQOk= X-Received: by 2002:a0d:e609:0:b0:2d6:b8b0:8608 with SMTP id p9-20020a0de609000000b002d6b8b08608mr23824993ywe.31.1647351076662; Tue, 15 Mar 2022 06:31:16 -0700 (PDT) MIME-Version: 1.0 References: <20220315042355.362810-1-luofei@unicloud.com> In-Reply-To: <20220315042355.362810-1-luofei@unicloud.com> From: Muchun Song Date: Tue, 15 Mar 2022 21:29:27 +0800 Message-ID: Subject: Re: [PATCH] hugetlbfs: fix description about atomic allocation of vmemmap pages when free huge page To: luofei Cc: Mike Kravetz , Andrew Morton , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 7cqitec6ubegt4iurp73xns1hpxkmbcm Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=iS+6HlPy; spf=pass (imf08.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9CC9A160005 X-HE-Tag: 1647351077-21422 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 15, 2022 at 12:24 PM luofei wrote: > > No matter what context update_and_free_page() is called in, > the flag for allocating the vmemmap page is fixed > (GFP_KERNEL | __GFP_NORETRY | __GFP_THISNODE), and no atomic > allocation is involved, so the description of atomicity here > is somewhat inappropriate. > > and the atomic parameter naming of update_and_free_page() is > somewhat misleading. > > Signed-off-by: luofei > --- > mm/hugetlb.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index f8ca7cca3c1a..239ef82b7897 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -1570,8 +1570,8 @@ static void __update_and_free_page(struct hstate *h, struct page *page) > > /* > * 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 allocate > + * use GFP_ATOMIC to allocate vmemmap pages. However, we can defer the > + * actual freeing in a workqueue to prevent waits caused by allocating > * the vmemmap pages. > * > * free_hpage_workfn() locklessly retrieves the linked list of pages to be > @@ -1617,16 +1617,14 @@ static inline void flush_free_hpage_work(struct hstate *h) > } > > static void update_and_free_page(struct hstate *h, struct page *page, > - bool atomic) > + bool delay) Hi luofei, At least, I don't agree with this change. The "atomic" means if the caller is under atomic context instead of whether using atomic GFP_MASK. The "delay" seems to tell the caller that it can undelay the allocation even if it is under atomic context (actually, it has no choice). But "atomic" can indicate the user is being asked to tell us if it is under atomic context. Thanks.