From: Dave Martin <Dave.Martin@arm.com>
To: chenfeng <puck.chen@hisilicon.com>
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
mark.rutland@arm.com, ard.biesheuvel@linaro.org,
lauraa@codeaurora.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Dan zhao <dan.zhao@hisilicon.com>,
Yiping Xu <xuyiping@hisilicon.com>,
suzhuangluan@hisilicon.com, qijiwen <qijiwen@hisilicon.com>,
oliver.fu@hisilicon.com,
Peter Panshilin <peter.panshilin@hisilicon.com>
Subject: Re: Question about the sparse memory section size
Date: Tue, 22 Sep 2015 12:17:27 +0100 [thread overview]
Message-ID: <20150922111723.GI6281@e103592.cambridge.arm.com> (raw)
In-Reply-To: <56010DDD.3080803@hisilicon.com>
On Tue, Sep 22, 2015 at 04:14:21PM +0800, chenfeng wrote:
> Hi all,
> The sparse memory section size, SECTION_SIZE_BITS, currently is 1GB
> for arm64 by default. However, it might generate wasted memmap memory
> space for those memory sections less than 1GB. e.g.
>
> for 512MB memory section, still 14MB(sizeof(struct page) *
> PAGES_PER_SECTION) memmap needs to be reserved. The wasted memmap
> space could be eliminated by changing memory section size from 1GB to
> 512M, but still some questions to be answered,
>
> 1) why arm64 uses 1GB as default setting?
> 2) any risk to change section size from 1GB to 512MB? like, any
> impact to performance since memory section number is increased.
For arm64 we have SPARSEMEM_VMEMMAP enabled by default, which enables
much of the wasted memmap backing memory to be reclaimed.
Take a look at arch/arm64/mm/init.c:free_unused_memmap().
This should reduce the amount of actual memory wasted on unused parts
of memmap. The virtual space stays wasted as you describe, but that's
plentiful on 64-bit arches.
You could try sticking some printks in there is you want to see how much
of the memmap the code successfully frees.
Cheers
---Dave
next prev parent reply other threads:[~2015-09-22 11:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 8:14 chenfeng
2015-09-22 11:17 ` Dave Martin [this message]
[not found] ` <13BC74040D0EF941B37FE727464B56DA8A5E2696@szxema508-mbx.china.huawei.com>
2015-09-23 12:08 ` 答复: " Dave P Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150922111723.GI6281@e103592.cambridge.arm.com \
--to=dave.martin@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=dan.zhao@hisilicon.com \
--cc=lauraa@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oliver.fu@hisilicon.com \
--cc=peter.panshilin@hisilicon.com \
--cc=puck.chen@hisilicon.com \
--cc=qijiwen@hisilicon.com \
--cc=suzhuangluan@hisilicon.com \
--cc=will.deacon@arm.com \
--cc=xuyiping@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome