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 2E216C433F5 for ; Sat, 12 Feb 2022 14:50:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A8526B0072; Sat, 12 Feb 2022 09:50:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 159086B0073; Sat, 12 Feb 2022 09:50:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01E706B0078; Sat, 12 Feb 2022 09:50:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by kanga.kvack.org (Postfix) with ESMTP id E7EB06B0072 for ; Sat, 12 Feb 2022 09:50:28 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 962DB181AC9C6 for ; Sat, 12 Feb 2022 14:50:28 +0000 (UTC) X-FDA: 79134413736.24.A70E861 Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf25.hostedemail.com (Postfix) with ESMTP id 7648BA0006 for ; Sat, 12 Feb 2022 14:50:27 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id bt13so33397167ybb.2 for ; Sat, 12 Feb 2022 06:50:26 -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=Su7AQ/5xwTbM+10TxtxCdpVbmI06ysx1kE8vo59J6GE=; b=J2RdaV7sbB5sJNP4qFBdwADQQDjK3aTvY8zLZx/JDCUvMr+p330G43ATMom+WfAOs7 OtGAQZnlVRFBgL/RTQjKL1TIgcOSPQrVRTX7uvsDcJ7B4NcUHLR2PXUAJbs/PLZYuhaF Fz2H2G5tDtAT35ha9NnAh50b+YFVLk1DN272G4SEVgHuBRV+ohNZOlDsLSNyViS4sMme PeGfb/YCmR2ZxHNa2eaNU2RYAK7HEJHD8EM4a0NacLt2IAu5vAN/mpe+jgSArEZeIp1X /FnFZOeHlGxk3gTYW8kbJiM6rN/NPC6L8Aduu+PJn8n0be/u5DL0ACECJshrljToWjSS CCLg== 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=Su7AQ/5xwTbM+10TxtxCdpVbmI06ysx1kE8vo59J6GE=; b=FmcY75UGDXR0XtRf9IS3zXILOYQmaRjs1RcGa/RTvcIcq7yNkWIJJn0fuC8omjvNib WVm9xXyh1DII6mgrsesaFPc9+6Z51DvBFy61NpQZMxbsQaAjB8KU5Hc2WwulILnlDhrD 8/R0WWqRqq/BpFqpBshQqRQPNMWubZlz0RiNw0izyU2ifNRQL5zxIUeXCBpwuJAbpkaB IuGQyixmXbq6DaYouocHjHFcryJKr4ci7wddVhYmrkZhgMOQxnAO8zHNlMl2rrmrFIWk t0wHImUk1vIitV0R8c+lmH8fGpCMcmZiEEfGNikwWqkQsHYXpv+66gvAjGMG7sJte8kS m/HQ== X-Gm-Message-State: AOAM533zsnJSDe4JNJ4yc1fkQhqA7YQ7wk0vbzjthzX6QcOugrG9AeZC wAIvcT2sjcmfUEj+9vf7eM6VuNkTz3O8c0W2Ya3jbQ== X-Google-Smtp-Source: ABdhPJwDUzQBxTRtxWwNY46Xv0JADh+f52XG44YUT4SrXJT3uIPLD0F239DDRKnvV/V4eRppK/aM7bAbaAEunNnv7Sw= X-Received: by 2002:a25:4742:: with SMTP id u63mr5594569yba.523.1644677426443; Sat, 12 Feb 2022 06:50:26 -0800 (PST) MIME-Version: 1.0 References: <20220210193345.23628-1-joao.m.martins@oracle.com> <20220210193345.23628-5-joao.m.martins@oracle.com> In-Reply-To: From: Muchun Song Date: Sat, 12 Feb 2022 22:49:49 +0800 Message-ID: Subject: Re: [PATCH v5 4/5] mm/sparse-vmemmap: improve memory savings 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: rspam12 X-Rspamd-Queue-Id: 7648BA0006 X-Stat-Signature: e6atrmdbjheyezj4r7z73hyeat11ws6q X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=J2RdaV7s; spf=pass (imf25.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-HE-Tag: 1644677427-770957 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 Sat, Feb 12, 2022 at 6:08 PM Muchun Song wrote: > > On Fri, Feb 11, 2022 at 8:37 PM Joao Martins wrote: > > > > On 2/11/22 07:54, Muchun Song wrote: > > > On Fri, Feb 11, 2022 at 3:34 AM Joao Martins wrote: > > > [...] > > >> pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node, > > >> - struct vmem_altmap *altmap) > > >> + struct vmem_altmap *altmap, > > >> + struct page *block) > > > > > > Why not use the name of "reuse" instead of "block"? > > > Seems like "reuse" is more clear. > > > > > Good idea, let me rename that to @reuse. > > > > >> { > > >> pte_t *pte = pte_offset_kernel(pmd, addr); > > >> if (pte_none(*pte)) { > > >> pte_t entry; > > >> void *p; > > >> > > >> - p = vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap); > > >> - if (!p) > > >> - return NULL; > > >> + if (!block) { > > >> + p = vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap); > > >> + if (!p) > > >> + return NULL; > > >> + } else { > > >> + /* > > >> + * When a PTE/PMD entry is freed from the init_mm > > >> + * there's a a free_pages() call to this page allocated > > >> + * above. Thus this get_page() is paired with the > > >> + * put_page_testzero() on the freeing path. > > >> + * This can only called by certain ZONE_DEVICE path, > > >> + * and through vmemmap_populate_compound_pages() when > > >> + * slab is available. > > >> + */ > > >> + get_page(block); > > >> + p = page_to_virt(block); > > >> + } > > >> entry = pfn_pte(__pa(p) >> PAGE_SHIFT, PAGE_KERNEL); > > >> set_pte_at(&init_mm, addr, pte, entry); > > >> } > > >> @@ -609,7 +624,8 @@ pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node) > > >> } > > >> > > >> static int __meminit vmemmap_populate_address(unsigned long addr, int node, > > >> - struct vmem_altmap *altmap) > > >> + struct vmem_altmap *altmap, > > >> + struct page *reuse, struct page **page) > > > > > > We can remove the last argument (struct page **page) if we change > > > the return type to "pte_t *". More simple, don't you think? > > > > > > > Hmmm, perhaps it is simpler, specially provided the only error code is ENOMEM. > > > > Albeit perhaps what we want is a `struct page *` rather than a pte. > > The caller can extract `struct page` from a pte. > > [...] > > > >> - if (vmemmap_populate(start, end, nid, altmap)) > > >> + if (pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) > > > > > > Should we add a judgment like "is_power_of_2(sizeof(struct page))" since > > > this optimization is only applied when the size of the struct page does not > > > cross page boundaries? > > > > Totally miss that -- let me make that adjustment. > > > > Can I ask which architectures/conditions this happens? > > E.g. arm64 when !CONFIG_MEMCG. Plus !CONFIG_SLUB even on x86_64. > > Thanks.