From: Wei Yang <richard.weiyang@gmail.com>
To: mgorman@techsingularity.net, jiang.liu@linux.intel.com,
mhocko@suse.com, akpm@linux-foundation.org, tj@kernel.org,
mingo@kernel.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [RFC] calc_memmap_size() isn't accurate and one suggestion to improve
Date: Tue, 28 Mar 2017 09:11:37 +0800 [thread overview]
Message-ID: <20170328011137.GA8655@WeideMacBook-Pro.local> (raw)
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]
Hi, masters,
# What I found
I found the function calc_memmap_size() may not be that accurate to get the
pages for memmap.
The reason is:
> memmap is allocated on a node base,
> while the calculation is on a zone base
This applies both to SPARSEMEM and FLATMEM.
For example, on my laptop with 6G memory, all the memmap space is allocated
from ZONE_NORMAL.
# My suggestion
Current code path is:
sparse_init() <- memmap allocated
zone_sizes_init()
free_area_init_nodes()
calculate_node_totalpages()
free_area_init_core() <- where we do the calculation
From the code snippet, memmap is already allocated in memblock, which
means we can get the information by comparing memblock.memory and
memblock.reserved.
My suggestion is to record this information in pg_data_t in
calculate_node_totalpages(), which is already doing the calculation on each
zone's spanned_pages and present_pages.
# Other solutions came to my mind
1. Assume all the memmap is allocated from the highest zone.
Pro:
Easy to calculate
Cor:
Not good to do this assumption. How to set the boundary. And there is the case
memory is allocated bottom-up.
2. Record the memmap area for each allocation
Pro:
Accurate and exact the size and zone index is recorded.
Cor:
Too expensive, especially when VMEMMAP && !ALLOC_MEM_MAP_TOGETHER. There would
be too many.
# Look for you comment
This code path applies to most of the arch, while I am not 100% for sure this
applies to all the arch. If isn't, this change may not be a good one.
The solution looks good to me, while I may miss some corner case or some
important facts.
Willing to hear from you :-)
--
Wei Yang
Help you, Help me
--
Wei Yang
Help you, Help me
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next reply other threads:[~2017-03-28 1:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-28 1:11 Wei Yang [this message]
2017-04-03 9:18 ` [RFC] calc_memmap_size() isn't accurate and one suggestion to improve Michal Hocko
2017-04-09 1:44 ` Wei Yang
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=20170328011137.GA8655@WeideMacBook-Pro.local \
--to=richard.weiyang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jiang.liu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=tj@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).