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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 01278C433DB for ; Thu, 14 Jan 2021 10:55:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 657F9239CF for ; Thu, 14 Jan 2021 10:55:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 657F9239CF 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 D32748D00D4; Thu, 14 Jan 2021 05:55:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CDF0F8D008E; Thu, 14 Jan 2021 05:55:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCF0C8D00D4; Thu, 14 Jan 2021 05:55:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0062.hostedemail.com [216.40.44.62]) by kanga.kvack.org (Postfix) with ESMTP id A3CCF8D008E for ; Thu, 14 Jan 2021 05:55:13 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6AB43180AD81D for ; Thu, 14 Jan 2021 10:55:13 +0000 (UTC) X-FDA: 77704073706.18.dad35_51034db27526 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 3FC3A100ED3DF for ; Thu, 14 Jan 2021 10:55:13 +0000 (UTC) X-HE-Tag: dad35_51034db27526 X-Filterd-Recvd-Size: 6432 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 10:55:12 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id i7so3522042pgc.8 for ; Thu, 14 Jan 2021 02:55:12 -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=BwMXHMt7GhzgcE2VNYydc3q3ayy6zmEsW948qf9k0OE=; b=XZONOtAXDDegjmVfiwAn9DskCEZKXL4FJwWxIA0x3CLQRYTcRAfvIy2YR/Eg6JNzBw 1noKWDAeMBjz9R87DFFOEMpASVaDuf3MhYFq6OnQcW9lCLUGGsPRiy85RsckggMIA0r4 eaJmjcesWQX1Iy02RpWLbufYnD0AJqa4lDemG7adypu/zu1Xs+bYthcrzaaHQ6Y88y9r PNAwHPkGl7wR/cOmQpeh5wGFz8KnnS6zl20j8idkDwPGejrehfxdiC0q1hPNOt9z7aKS MUfqlCSUO63et1m7RVXdeqhpD0R2GNugEUzaX63X+yE2zlKTosJQv0nec77fGXCxKmP8 A65g== 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=BwMXHMt7GhzgcE2VNYydc3q3ayy6zmEsW948qf9k0OE=; b=XIhkiPN1ScjN/tCq7d3beNGW/74QrRiryuOY8lpgOlx+vj6+0K7udHRY1DMDB0wY7r JXbKxdjj6dLmThKKcDEwIMg8jrZTxJDvKQTQe3piboVPYPGoGaeXbQLqCydRkkys5xHp KzmFNB5y9xnqM5I4zH16RQFX+ijm7io42Trk4YPofGS9OWyvwamY8kv+PdMJXta4ArEB 6b102+pgZ+RiwJk4DlaALNjxeFYMMimkUu1ROYZfjVO67Umy4mBJD5aZbxUjin41HQb8 TZCKkWRdaJG87ZcDWE4dVyZjWO+x6XKrjh0V3eiL+T/UyWzGdA6u8ee+0RyuWRSsxP7p YsvA== X-Gm-Message-State: AOAM531Vw4Dad8Phb3hfquqM2vJgg2AfTwzJJMoQ/bX0f125LX26IMH/ u2mkF3YxcXQSuJ7sdRURO6HsUFfomfwHch4Slq/uEg== X-Google-Smtp-Source: ABdhPJwAXaQYvHyFORw2v2RQzVwh0nIznbb7WHGX2ESFOUPhSYnlg3ysGgcXfCtYITBX4lkDn64KXJZwFtfvowMAzAo= X-Received: by 2002:a63:480f:: with SMTP id v15mr6910119pga.341.1610621711342; Thu, 14 Jan 2021 02:55:11 -0800 (PST) MIME-Version: 1.0 References: <20210106141931.73931-1-songmuchun@bytedance.com> <20210106141931.73931-5-songmuchun@bytedance.com> <20210112080453.GA10895@linux> <20210113092028.GB24816@linux> In-Reply-To: From: Muchun Song Date: Thu, 14 Jan 2021 18:54:30 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v12 04/13] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page To: Mike Kravetz , Oscar Salvador Cc: Jonathan Corbet , Thomas Gleixner , mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , viro@zeniv.linux.org.uk, 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 , Michal Hocko , "Song Bao Hua (Barry Song)" , David Hildenbrand , =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel Content-Type: text/plain; charset="UTF-8" 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, Jan 14, 2021 at 7:27 AM Mike Kravetz wrote: > > On 1/13/21 1:20 AM, Oscar Salvador wrote: > > On Tue, Jan 12, 2021 at 07:33:33PM +0800, Muchun Song wrote: > >>> It seems a bit odd to only pass "start" for the BUG_ON. > >>> Also, I kind of dislike the "addr += PAGE_SIZE" in vmemmap_pte_range. > >>> > >>> I wonder if adding a ".remap_start_addr" would make more sense. > >>> And adding it here with the vmemmap_remap_walk init. > >> > >> How about introducing a new function which aims to get the reuse > >> page? In this case, we can drop the BUG_ON() and "addr += PAGE_SIZE" > >> which is in vmemmap_pte_range. The vmemmap_remap_range only > >> does the remapping. > > > > How would that look? > > It might be good, dunno, but the point is, we should try to make the rules as > > simple as possible, dropping weird assumptions. > > > > Callers of vmemmap_remap_free should know three things: > > > > - Range to be remapped > > - Addr to remap to > > - Current implemantion needs addr to be remap to to be part of the complete > > range > > > > right? > > And, current implementation needs must have remap addr be the first in the > complete range. This is just because of the way the page tables are walked > for remapping. The remap/reuse page must be found first so that the following > pages can be remapped to it. You are right. > > That implementation seems to be the 'most efficient' for hugetlb pages where > we want vmemmap pages n+3 and beyond mapped to n+2. > > In a more general purpose vmemmap_remap_free implementation, the reuse/remap > address would not necessarily need to be related to the range. However, this > would require a separate page table walk/validation for the reuse address > independent of the range. This may be what Muchun was proposing for 'a new > function which aims to get the reuse page'. Agree. > > IMO, the decision on how to implement depends on the intended use case. > - If this is going to be hugetlb only (or perhaps generic huge page only) > functionality, then I am OK with an efficient implementation that has > some restrictions. > - If we see this being used for more general purpose remapping, then we > should go with a more general purpose implementation. I think this approach may be only suitable for generic huge page only. So we can implement it only for huge page. Hi Oscar, What's your opinion about this? > > Again, just my opinion. > -- > Mike Kravetz