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 436B3C55ABD for ; Fri, 13 Nov 2020 04:18:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A24F42076B for ; Fri, 13 Nov 2020 04:18:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bytedance-com.20150623.gappssmtp.com header.i=@bytedance-com.20150623.gappssmtp.com header.b="JhMbe0h7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A24F42076B 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 B06126B005C; Thu, 12 Nov 2020 23:18:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A8DE56B005D; Thu, 12 Nov 2020 23:18:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92E346B0068; Thu, 12 Nov 2020 23:18:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id 625BA6B005C for ; Thu, 12 Nov 2020 23:18:46 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 042D5180AD801 for ; Fri, 13 Nov 2020 04:18:45 +0000 (UTC) X-FDA: 77478089052.04.stamp24_11015f32730c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id D375080051B0 for ; Fri, 13 Nov 2020 04:18:45 +0000 (UTC) X-HE-Tag: stamp24_11015f32730c X-Filterd-Recvd-Size: 6059 Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Nov 2020 04:18:45 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id h16so1990996pgb.7 for ; Thu, 12 Nov 2020 20:18:45 -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=QoQQYCm0CUI1d3dFcipn72mQMnKWNV7T/6zPt9SRkDM=; b=JhMbe0h76w8OnmRD67vqzsLImyr/I+HBgst0M3grAdYQtypY39XAU7r1pxUDVxoHup rNbWOcyhrPRBREEmks6mN/NkjP8fGXt64xtL1zSbxhNmYBkvc/iz7LGKO2d4OrB16A/Q 2qn1pHpPryKku+WNUODMpAhN8C3PfKnY7jkO4/tLK5VzHlSNgYhgaOJeDc4LeQ7Zr8Q2 xCSLxo/B2vYAEi3ZROc0DOVNjxy3qRrAJN2WqRPmdSTcehQVwo+FxCTCGW1QV3aWpKEs 9JQl1UaUYhs8kBwcs6Dc5i0BqtQ3ADo0627YIDhwYdM4COkTnxrnw2Ouog98fxLWS6D9 Tsng== 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=QoQQYCm0CUI1d3dFcipn72mQMnKWNV7T/6zPt9SRkDM=; b=gD7pq/qY1zdnWnIn8hghv02D3AEOdOyI5cebbbCHwDZ2EbOWtNdcRH9t2VWhXHRpmN bWrUwQR9p7TW9e1FSiK0JiPPAXbVivTU+dRyn/c13N8ouNbd5kpoIXOpR951nXAv9Jh6 AF19+2v4z0zxRbj/JSZW1s1zFREiDQeUvni4PSZqSXFfG3ZM+JRGFkhrX056EqANB4zy +ddk5n5TqX9mxVByBskWjCE/tzxroYzlq8e82UU1VBNZdFZ00NoVvpidynHivamYzT7v 1UdK1Vwszj+7p07hXHOcliXw5bvtgtckOfHAiolfyoenzElWl70RsYPm6yWku93Vgxtk JuZA== X-Gm-Message-State: AOAM530/2+0Txr6CktmVc7WxGHgWd+Rp03Sx0+sWc9ixJeJBi/22XjaO LLXeXNShgisq8bxsKXOArLsD4O3ojO/lns9jZwC/vg== X-Google-Smtp-Source: ABdhPJysNzFyG8GxRiZ3O2K/cMctulLuiEkBVF1gU2Xhkrh896y5T/IU+i9GQI8nyGwtxr5CK1N0HtfbnW7JNorvmB4= X-Received: by 2002:a17:90b:88b:: with SMTP id bj11mr709269pjb.229.1605241124066; Thu, 12 Nov 2020 20:18:44 -0800 (PST) MIME-Version: 1.0 References: <20201108141113.65450-1-songmuchun@bytedance.com> <20201108141113.65450-6-songmuchun@bytedance.com> <9dc62874-379f-b126-94a7-5bd477529407@oracle.com> In-Reply-To: From: Muchun Song Date: Fri, 13 Nov 2020 12:18:07 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v3 05/21] mm/hugetlb: Introduce pgtable allocation/freeing helpers To: Mike Kravetz 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 , Oscar Salvador , Michal Hocko , 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 Fri, Nov 13, 2020 at 8:38 AM Mike Kravetz wrote: > > On 11/10/20 7:41 PM, Muchun Song wrote: > > On Wed, Nov 11, 2020 at 8:47 AM Mike Kravetz wrote: > >> > >> On 11/8/20 6:10 AM, Muchun Song wrote: > >> I am reading the code incorrectly it does not appear page->lru (of the huge > >> page) is being used for this purpose. Is that correct? > >> > >> If it is correct, would using page->lru of the huge page make this code > >> simpler? I am just missing the reason why you are using > >> page_huge_pte(page)->lru > > > > For 1GB HugeTLB pages, we should pre-allocate more than one page > > table. So I use a linked list. The page_huge_pte(page) is the list head. > > Because the page->lru shares storage with page->pmd_huge_pte. > > Sorry, but I do not understand the statement page->lru shares storage with > page->pmd_huge_pte. Are you saying they are both in head struct page of > the huge page? > > Here is what I was suggesting. If we just use page->lru for the list > then vmemmap_pgtable_prealloc() could be coded like the following: > > static int vmemmap_pgtable_prealloc(struct hstate *h, struct page *page) > { > struct page *pte_page, *t_page; > unsigned int nr = pgtable_pages_to_prealloc_per_hpage(h); > > if (!nr) > return 0; > > /* Store preallocated pages on huge page lru list */ > INIT_LIST_HEAD(&page->lru); > > while (nr--) { > pte_t *pte_p; > > pte_p = pte_alloc_one_kernel(&init_mm); > if (!pte_p) > goto out; > list_add(&virt_to_page(pte_p)->lru, &page->lru); > } > > return 0; > out: > list_for_each_entry_safe(pte_page, t_page, &page->lru, lru) > pte_free_kernel(&init_mm, page_to_virt(pte_page)); > return -ENOMEM; > } > > By doing this we could eliminate the routines, > vmemmap_pgtable_init() > vmemmap_pgtable_deposit() > vmemmap_pgtable_withdraw() > and simply use the list manipulation routines. Now I know what you mean. Yeah, just use page->lru can make code simply. Thanks for your suggestions. > > To me, that looks simpler than the proposed code in this patch. > -- > Mike Kravetz -- Yours, Muchun