lkml.org 
[lkml]   [2020]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject答复: [PATCH v2] arm64: mm: free unused memma p for sparse memory model that define VMEMMAP
    Date
    Hi, Barry

    I have changed SECTION_SIZE_BITS to 27 in our products, but I don't have to submit it.

    -----邮件原件-----
    发件人: Song Bao Hua (Barry Song)
    发送时间: 2020年11月16日 16:34
    收件人: Catalin Marinas <catalin.marinas@arm.com>; Mike Rapoport <rppt@linux.ibm.com>; liwei (CM) <liwei213@huawei.com>
    抄送: will@kernel.org; Xiaqing (A) <saberlily.xia@hisilicon.com>; Chenfeng (puck) <puck.chen@hisilicon.com>; butao <butao@hisilicon.com>; fengbaopeng <fengbaopeng2@hisilicon.com>; nsaenzjulienne@suse.de; steve.capper@arm.com; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; sujunfei <sujunfei2@hisilicon.com>; Linuxarm <linuxarm@huawei.com>
    主题: RE: [PATCH v2] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP



    > -----Original Message-----
    > From: Catalin Marinas [mailto:catalin.marinas@arm.com]
    > Sent: Friday, September 4, 2020 12:06 AM
    > To: Mike Rapoport <rppt@linux.ibm.com>
    > Cc: liwei (CM) <liwei213@huawei.com>; will@kernel.org; Xiaqing (A)
    > <saberlily.xia@hisilicon.com>; Chenfeng (puck)
    > <puck.chen@hisilicon.com>; butao <butao@hisilicon.com>; fengbaopeng
    > <fengbaopeng2@hisilicon.com>; nsaenzjulienne@suse.de;
    > steve.capper@arm.com; Song Bao Hua (Barry Song)
    > <song.bao.hua@hisilicon.com>; linux-arm-kernel@lists.infradead.org;
    > linux-kernel@vger.kernel.org; sujunfei <sujunfei2@hisilicon.com>
    > Subject: Re: [PATCH v2] arm64: mm: free unused memmap for sparse
    > memory model that define VMEMMAP
    >
    > On Mon, Aug 17, 2020 at 11:04:05AM +0300, Mike Rapoport wrote:
    > > On Wed, Aug 12, 2020 at 09:06:55AM +0800, Wei Li wrote:
    > > > For the memory hole, sparse memory model that define
    > SPARSEMEM_VMEMMAP
    > > > do not free the reserved memory for the page map, this patch do it.
    > >
    > > I've been thinking about it a bit more and it seems that instead of
    > > freeing unused memory map it would be better to allocate the exact
    > > memory map from the beginning.
    > >
    > > In sparse_init_nid() we can replace PAGES_PER_SECTION parameter to
    > > __populate_section_memmap() with the calculated value for
    > > architectures that define HAVE_ARCH_PFN_VALID.
    >
    > Or just use a smaller PAGES_PER_SECTION and reduce the waste ;).
    >
    > Just to be clear, are you suggesting that we should use pfn_valid() on
    > the pages within a section to calculate the actual range? The
    > pfn_valid() implementation on arm64 checks for the validity of a
    > sparse section, so this would be called from within the sparse_init()
    > code path. I hope there's no dependency but I haven't checked. If it
    > works, it's fine by me, it solves the FLATMEM mem_map freeing as well.
    >
    > With 4KB pages on arm64, vmemmap_populate() stops at the pmd level, so
    > it always allocates PMD_SIZE. Wei's patch also only frees in PMD_SIZE
    > amounts. So, with a sizeof(struct page) of 64 (2^6), a PMD_SIZE
    > mem_map section would cover 2^(21-6) pages, so that's equivalent to a
    > SECTION_SIZE_BITS of 21-6+12 = 27.
    >
    > If we reduce SECTION_SIZE_BITS to 27 or less, this patch is a no-op.

    It would be the simplest way to fix this issue. It seems X86_64 is also using 27.

    @wei, has you ever tried to send a patch to change SECTION_SIZE_BITS to 27 for ARM64?

    >
    > --
    > Catalin

    Thanks
    Barry
    \
     
     \ /
      Last update: 2020-11-16 09:46    [W:3.239 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site