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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 474F2C433E0 for ; Thu, 11 Mar 2021 08:50:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A225D64FAA for ; Thu, 11 Mar 2021 08:50:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A225D64FAA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 205508D0297; Thu, 11 Mar 2021 03:50:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B4618D028E; Thu, 11 Mar 2021 03:50:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02EC98D0297; Thu, 11 Mar 2021 03:50:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id DC8568D028E for ; Thu, 11 Mar 2021 03:50:02 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A0615180ACEF0 for ; Thu, 11 Mar 2021 08:50:02 +0000 (UTC) X-FDA: 77906971044.11.ED32104 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf06.hostedemail.com (Postfix) with ESMTP id 5C17CC0007C2 for ; Thu, 11 Mar 2021 08:50:02 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id j12so13927866pfj.12 for ; Thu, 11 Mar 2021 00:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LumJ6Q1wXFZBFikK5CldqzLK8H4AUjOU6TLuse65FxA=; b=HjGBVFvOV4KrzmLYJIkyax4nE8Fxra4DK5g8RQ+533/rNDRTJMlGtSBKsSyX/p190B 2dOfrYUEzXKmZNc0OUqKwOZBU553rFRt3qeHFqJYJEeBsiOanNfvWaH4gri5ul6B4IPg tIvNcLGAIHKzOvEPIPMmtQXdBCti9XdYGkLkXrIYpGn2zn+Bk7Vo8S0tp6Qb/iw//AVK gRd57bUnFlXoafkGWKJQRCWGQv2//A6bp+sYfZd1PzwTRC+zWcXjT/qhKehpiGQj15oj YsTsJKxoWA3xpZ4TvMEjmTUkozW9fVJ1/bUKTxBs0gL5Je6ptpXtaGIsjw9v73RoeXKA jM3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LumJ6Q1wXFZBFikK5CldqzLK8H4AUjOU6TLuse65FxA=; b=Rw4fokcJT0jtIevtF5SE5Z4zrY2IhJXg8ASvO4U+Q8Nozp5mL0zPlbmfVnp72SaIXy R48rkB6tsBpvuF6P7kdWznSSl4s/Zu9qS4gcl6U+Wtux5Luqmkg6HoZR7CqQfeA0/+46 fmwUJYYgQvgl+NhfdR2N8+pOnei1yujv1PY1TMSXuwr53oHMBUy7f+mcifHXMOaD1HuX 0ffOYhRpT/nuiNdBkFuesX0uZ4dNXwcyLV3+EfMP7AITQn1xQW2t9yx3rirzefEPXahS xo/J7vy83jbuPF+ax/7Z6YZ2ZpOAIM3Vb/AottyDgwlAuWImtCZosAgirUy8e5h5syrm d1hQ== X-Gm-Message-State: AOAM5320iNR4/SGTKZOtvEzZ55vyXNz3Fa7gnZ9rDXpbY+NycX4z4OEu wmqfzZJe0GIIG4ShIPgSZAjx4sB214keFU4qr9uTeg== X-Google-Smtp-Source: ABdhPJxceJjEqAKD1t/gxkQLylZF41D2M2U0liujlLCHHaLE8YBg4pzWREUBsMNlKzcLXiv2jCvoYLRE4DTN1sN48RA= X-Received: by 2002:a63:141e:: with SMTP id u30mr6553172pgl.31.1615452601095; Thu, 11 Mar 2021 00:50:01 -0800 (PST) MIME-Version: 1.0 References: <20210308102807.59745-1-songmuchun@bytedance.com> <20210308102807.59745-5-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Thu, 11 Mar 2021 16:49:24 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v18 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page To: Michal Hocko Cc: Jonathan Corbet , Mike Kravetz , Thomas Gleixner , Ingo Molnar , bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , Alexander Viro , Andrew Morton , paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, Randy Dunlap , oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, Mina Almasry , David Rientjes , Matthew Wilcox , Oscar Salvador , "Song Bao Hua (Barry Song)" , David Hildenbrand , =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Joao Martins , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel , Chen Huang , Bodeddula Balasubramaniam Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: nzh6ieszwnrza417ptkn36wmzkzd8w76 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5C17CC0007C2 Received-SPF: none (bytedance.com>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mail-pf1-f179.google.com; client-ip=209.85.210.179 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615452602-304626 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 Thu, Mar 11, 2021 at 4:46 PM Michal Hocko wrote: > > On Thu 11-03-21 12:26:32, Muchun Song wrote: > > On Wed, Mar 10, 2021 at 11:19 PM Michal Hocko wrote: > > > > > > On Mon 08-03-21 18:28:02, Muchun Song wrote: > [...] > > > > @@ -1771,8 +1813,12 @@ int dissolve_free_huge_page(struct page *page) > > > > h->free_huge_pages--; > > > > h->free_huge_pages_node[nid]--; > > > > h->max_huge_pages--; > > > > - update_and_free_page(h, head); > > > > - rc = 0; > > > > + rc = update_and_free_page(h, head); > > > > + if (rc) { > > > > + h->surplus_huge_pages--; > > > > + h->surplus_huge_pages_node[nid]--; > > > > + h->max_huge_pages++; > > > > > > This is quite ugly and confusing. update_and_free_page is careful to do > > > the proper counters accounting and now you just override it partially. > > > Why cannot we rely on update_and_free_page do the right thing? > > > > Dissolving path is special here. Since update_and_free_page failed, > > the number of surplus pages was incremented. Surplus pages are > > the number of pages greater than max_huge_pages. Since we are > > incrementing max_huge_pages, we should decrement (undo) the > > addition to surplus_huge_pages and surplus_huge_pages_node[nid]. > > Can we make dissolve_free_huge_page less special or tell > update_and_free_page to not account against dissolve_free_huge_page? Of course can. Thanks. > -- > Michal Hocko > SUSE Labs