linux-kernel - Re: Question about the sparse memory section size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150922111723.GI6281@e103592.cambridge.arm.com>
Date:	Tue, 22 Sep 2015 12:17:27 +0100
From:	Dave Martin <Dave.Martin@....com>
To:	chenfeng <puck.chen@...ilicon.com>
Cc:	catalin.marinas@....com, will.deacon@....com, mark.rutland@....com,
	ard.biesheuvel@...aro.org, lauraa@...eaurora.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Dan zhao <dan.zhao@...ilicon.com>,
	Yiping Xu <xuyiping@...ilicon.com>, suzhuangluan@...ilicon.com,
	qijiwen <qijiwen@...ilicon.com>, oliver.fu@...ilicon.com,
	Peter Panshilin <peter.panshilin@...ilicon.com>
Subject: Re: Question about the sparse memory section size

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/