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 27C61C433EF for ; Fri, 24 Jun 2022 08:03:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5274B8E01EE; Fri, 24 Jun 2022 04:03:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D75C8E01E7; Fri, 24 Jun 2022 04:03:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C6368E01EE; Fri, 24 Jun 2022 04:03:49 -0400 (EDT) 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 2E1B28E01E7 for ; Fri, 24 Jun 2022 04:03:49 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 04D982151B for ; Fri, 24 Jun 2022 08:03:48 +0000 (UTC) X-FDA: 79612390578.01.791F7F9 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf08.hostedemail.com (Postfix) with ESMTP id ECC1D16000E for ; Fri, 24 Jun 2022 08:03:47 +0000 (UTC) Received: by mail-pj1-f46.google.com with SMTP id t3-20020a17090a510300b001ea87ef9a3dso2062842pjh.4 for ; Fri, 24 Jun 2022 01:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=s/aQkZT/+2YcvxV9aXxlZHqNRowREfHb6F3Nptk8s7o=; b=WhFGELdR/RtberGg47WTsERtwgZ9s5MslETlO9JE75M3s1+glUPLMpUnejl3c5px2D 5QyuxWW2zAm2YD3ZkpOsjjoxZebMTOGuO8jIDzsg5rfrM+iLKHY70KgWdB2rLoxawTtq ue+RchUgEmZJ3S5t7mrddkmjodTw30lN2kFhtfiMz8qXceCH8ah+QWuxnhv3gIsiXfC4 AAStOBtmWtU5nXN/gJPLdsCDRCb3tZtLgmcRD9SYetXjd+bf43lHYxjKS0IfZ12BSxGq Tm26xqgFKQBo5/jvvomJM3l11g7UMmFQhxKnDJnj9nqcFS738XZcvT9EyyN7kN6es61x 28hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=s/aQkZT/+2YcvxV9aXxlZHqNRowREfHb6F3Nptk8s7o=; b=Y5sVwv2SeKHvvqj/EOsRFnlRgPh9FIyoJd3qVVaICh9Q7/bG//slV02srOFHqAgVwI ajZf+ZEXqO0tg2al2p9/YcLePFoysQZEcOUuz/Tuz5LeL/t0GRWr/MWChRHRTR4VGosc YaEfmIwnC/D+K7aKM0D6giIt/gTetBZlbXf2ci+BO81DWhny8Uh5TYzt6yz4u+2fQ4fE hVDgCe8bL5XSxvRRi0Ts9KusOUOfu2vtM6TsIpxSD0glFBipDT647HiLpbWX1UY8xbP+ OGsYQID1h9fENfmlh4N2VduiO8Qpm2Zi6rnekWOdSkI1bSjTu59uzwmuOb3SfHfdH9HG 1quQ== X-Gm-Message-State: AJIora+6gAuvUSyc6onB70Tv5cZgqbqIxhY3TynAb4VahstIHeJndTtx XvOyBCkXcP/SlFhqs4c8J2gyrw== X-Google-Smtp-Source: AGRyM1tvcvz9tpwEpWJiZAV/av7x9hQWUyoitwq7CE0hDgBShRrgeY97PjrKG7XJAFAr/1witvlPXg== X-Received: by 2002:a17:90b:224a:b0:1ec:d128:a82d with SMTP id hk10-20020a17090b224a00b001ecd128a82dmr2643657pjb.3.1656057826594; Fri, 24 Jun 2022 01:03:46 -0700 (PDT) Received: from localhost ([139.177.225.231]) by smtp.gmail.com with ESMTPSA id z29-20020a63191d000000b0040c9774b332sm927606pgl.48.2022.06.24.01.03.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jun 2022 01:03:46 -0700 (PDT) Date: Fri, 24 Jun 2022 16:03:42 +0800 From: Muchun Song To: Miaohe Lin Cc: Naoya Horiguchi , Andrew Morton , David Hildenbrand , Mike Kravetz , Liu Shixin , Yang Shi , Oscar Salvador , Naoya Horiguchi , linux-kernel@vger.kernel.org, Linux-MM Subject: Re: [PATCH v2 1/9] mm/hugetlb: remove checking hstate_is_gigantic() in return_unused_surplus_pages() Message-ID: References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> <20220623235153.2623702-2-naoya.horiguchi@linux.dev> <0b69e3ef-0123-4575-b68d-4d9b2067aa0e@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b69e3ef-0123-4575-b68d-4d9b2067aa0e@huawei.com> ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=WhFGELdR; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf08.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656057828; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=s/aQkZT/+2YcvxV9aXxlZHqNRowREfHb6F3Nptk8s7o=; b=tZIZU+IhWYefM1LOaQLnOeoG2tYcBf51gaJMsgzc9/dxDQcu2+OuQqIwfikRUSpEamU9UX BFufroD6pZ5tJMi4jvFLFxfDY7cAtUlRT8pF6e62pILP5gX+cV+YbVRDtzfz9yLIun7tgk JNvVrWn/Bcq1BI3D53kHtYQzJzOIC54= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656057828; a=rsa-sha256; cv=none; b=5rLKBzwp3FRyxisFF7A+ZKYiYke0GHMzhGg58o4+8Tar7ahk+HOzMyRatwjHfKDaWznQxY evpafCfmTHu287hjIXkLpbkNjt3bzCZ5+5KLSZL40uzA3koqO38Euw7oYyAiH7kksTgKYI cO+K0IwAlB/jDwzUwfZMZ0WBf4gsH28= X-Stat-Signature: xab1878idx1z6j7ozard7hyfj1zmchsu X-Rspamd-Queue-Id: ECC1D16000E X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=WhFGELdR; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf08.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-Rspamd-Server: rspam12 X-HE-Tag: 1656057827-329682 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 Fri, Jun 24, 2022 at 10:25:48AM +0800, Miaohe Lin wrote: > On 2022/6/24 7:51, Naoya Horiguchi wrote: > > From: Naoya Horiguchi > > > > I found a weird state of 1GB hugepage pool, caused by the following > > procedure: > > > > - run a process reserving all free 1GB hugepages, > > - shrink free 1GB hugepage pool to zero (i.e. writing 0 to > > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages), then > > - kill the reserving process. > > > > , then all the hugepages are free *and* surplus at the same time. > > > > $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages > > 3 > > $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages > > 3 > > $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/resv_hugepages > > 0 > > $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/surplus_hugepages > > 3 > > > > This state is resolved by reserving and allocating the pages then > > freeing them again, so this seems not to result in serious problem. > > But it's a little surprizing (shrinking pool suddenly fails). > > > > This behavior is caused by hstate_is_gigantic() check in > > return_unused_surplus_pages(). This was introduced so long ago in 2008 > > by commit aa888a74977a ("hugetlb: support larger than MAX_ORDER"), and > > it seems to me that this check is no longer unnecessary. Let's remove it. > > s/unnecessary/necessary/ > > > > > Signed-off-by: Naoya Horiguchi > > --- > > mm/hugetlb.c | 4 ---- > > 1 file changed, 4 deletions(-) > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index a57e1be41401..c538278170a2 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -2432,10 +2432,6 @@ static void return_unused_surplus_pages(struct hstate *h, > > /* Uncommit the reservation */ > > h->resv_huge_pages -= unused_resv_pages; > > > > - /* Cannot return gigantic pages currently */ > > - if (hstate_is_gigantic(h)) > > - goto out; > > - > > IIUC it might be better to do the below check: > /* > * Cannot return gigantic pages currently if runtime gigantic page > * allocation is not supported. > */ > if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) > goto out; > The change looks good to me. However, the comments above is unnecessary since gigantic_page_runtime_supported() is straightforward. Thanks. > But I might be miss something. > > Thanks. > > > /* > > * Part (or even all) of the reservation could have been backed > > * by pre-allocated pages. Only free surplus pages. > > > >