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 76D0CC433EF for ; Fri, 11 Feb 2022 05:07:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6998B6B0074; Fri, 11 Feb 2022 00:07:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 647F36B0075; Fri, 11 Feb 2022 00:07:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 510F26B0078; Fri, 11 Feb 2022 00:07:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 3E8C86B0074 for ; Fri, 11 Feb 2022 00:07:51 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E98BE22773 for ; Fri, 11 Feb 2022 05:07:50 +0000 (UTC) X-FDA: 79129316700.01.2D21AFA Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf09.hostedemail.com (Postfix) with ESMTP id A0C2E140009 for ; Fri, 11 Feb 2022 05:07:49 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id c6so21706407ybk.3 for ; Thu, 10 Feb 2022 21:07:49 -0800 (PST) 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=33X30vxk37dYzlKfVsNBndW9y5tzzn+eqam1oXj5DfU=; b=K2t7CEZ+mg5lBHC6Nfm4ggzoDdrPcmY9ShGUEBWXtZTTQvZLFbbgmiiwAsXApjq/AY KRFAQR7JAxBB7aEXM2WuPUO/UIgyPUT/tQgHMAeoLiYmhpuj1/e8qLBM2fiqhsCDknYV D+d+hTQ6X2sh2NRFUlkpUYpmNGHmihDBR1FiXjy70Mz6t3nageB0Dmfg5QKNSjqCsPt4 sBVaF1GursnStNLXh4RnDGjCKlzC5erE485WaGp0BbHyCJB3nNnVrFzZk9Gleo8YAGpP PijdDg9FS+yJyi5Aa6nhv97RLbRAG34Pg3vU6G2CNRrD5hw6lhV0vzYJa5CAQQad71/+ Zb4w== 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=33X30vxk37dYzlKfVsNBndW9y5tzzn+eqam1oXj5DfU=; b=uHQlFF4olKoL+hbuP+IqBKLNmMLAHmSCFCmIqh8fVEXy+qEhCWaUCMt4VzpKg1JnCX lK2HFEh3cq7m1sFGIBJ2mPzYpxOIs/KbZuEB7yONK5FsAU1uOzrpUoWmeiRftZnCDX/J tIk2vgH448kJ0SGcMz8PaAOk/3YN/74QSkMdRjz1+raADMIMURXh96EGx5gWNWTVYCi+ WHFNCbq0D03S0TjL1YgTbmlMlqyPpPFwU90329K+VhT3wo4FBblIzTHUnxXd/Db7m6+H ZjDR1zZ5a0PlLASJX/ymVT+rMgl/HyV6x+fs4jKNSJ5YxqbIXJJAAFKWDmqBKAdcAmiU kIrA== X-Gm-Message-State: AOAM533r1t9KrxQ1Kfwy/0SHTzl+9wQDb9Tc9qfgLLO9aoXwczovvtZ2 FbuRdLwv+7HEZOXqOIH+our/JVIMiREX85z/pZg59A== X-Google-Smtp-Source: ABdhPJyxIcJRA3uyrQa6x9yxKUYyyPEjOzENFGfmwumjFTCzNfg1VvCaXqVbuX7V1DM5nDMFnV/WYvxy3qDITrJrmbc= X-Received: by 2002:a81:ef04:: with SMTP id o4mr75353ywm.458.1644556068755; Thu, 10 Feb 2022 21:07:48 -0800 (PST) MIME-Version: 1.0 References: <20220210193345.23628-1-joao.m.martins@oracle.com> <20220210193345.23628-6-joao.m.martins@oracle.com> In-Reply-To: <20220210193345.23628-6-joao.m.martins@oracle.com> From: Muchun Song Date: Fri, 11 Feb 2022 13:07:11 +0800 Message-ID: Subject: Re: [PATCH v5 5/5] mm/page_alloc: reuse tail struct pages for compound devmaps To: Joao Martins Cc: Linux Memory Management List , Dan Williams , Vishal Verma , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A0C2E140009 X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=K2t7CEZ+; spf=pass (imf09.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Stat-Signature: 81p79ewiatqfuj8weepuues34tm8uayk X-HE-Tag: 1644556069-482655 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, Feb 11, 2022 at 3:34 AM Joao Martins wrote: > > Currently memmap_init_zone_device() ends up initializing 32768 pages > when it only needs to initialize 128 given tail page reuse. That > number is worse with 1GB compound pages, 262144 instead of 128. Update > memmap_init_zone_device() to skip redundant initialization, detailed > below. > > When a pgmap @vmemmap_shift is set, all pages are mapped at a given > huge page alignment and use compound pages to describe them as opposed > to a struct per 4K. > > With @vmemmap_shift > 0 and when struct pages are stored in ram > (!altmap) most tail pages are reused. Consequently, the amount of > unique struct pages is a lot smaller that the total amount of struct > pages being mapped. > > The altmap path is left alone since it does not support memory savings > based on compound pages devmap. > > Signed-off-by: Joao Martins > --- > mm/page_alloc.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index cface1d38093..c10df2fd0ec2 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -6666,6 +6666,20 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn, > } > } > > +/* > + * With compound page geometry and when struct pages are stored in ram most > + * tail pages are reused. Consequently, the amount of unique struct pages to > + * initialize is a lot smaller that the total amount of struct pages being > + * mapped. This is a paired / mild layering violation with explicit knowledge > + * of how the sparse_vmemmap internals handle compound pages in the lack > + * of an altmap. See vmemmap_populate_compound_pages(). > + */ > +static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, > + unsigned long nr_pages) > +{ > + return !altmap ? 2 * (PAGE_SIZE/sizeof(struct page)) : nr_pages; > +} > + This means only the first 2 pages will be modified, the reset 6 or 4094 pages do not. In the HugeTLB case, those tail pages are mapped with read-only to catch invalid usage on tail pages (e.g. write operations). Quick question: should we also do similar things on DAX? Thanks.