linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ss ss <nizhan.chen@gmail.com>
To: linux-mm@kvack.org
Cc: Richard Davies <richard@arachsys.com>,
	Shaohua Li <shli@kernel.org>, Rik van Riel <riel@redhat.com>,
	Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	wency@cn.fujitsu.com, Bob Picco <bob.picco@hp.com>,
	Dave Hansen <haveblue@us.ibm.com>
Subject: sparsemem issues
Date: Tue, 25 Sep 2012 19:27:42 +0800	[thread overview]
Message-ID: <CAEkdkmVnnCCHvrFzhib_USGQGQYc7UhQjO-nTyp+RLiTXjRtGA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

Hi all,

This is my first time send email to mm community, if something is wrong or
silly, please forgive me.
I have some confusions of sparsemem:

1. sparsemem

It seems that all mem_sections descriptors (except the second level if use
sparsemem extreme )are allocated
before memory_present, then when the are allocated ?

2. sparsemem extreme

sparsemem extreme implementation [commit : 3e347261a80b57df] changelog:

 "This two level layout scheme is able to achieve smaller memory
requirements for SPARSEMEM
  with the tradeoff of an additional shift and load when fetching the
memory section."

then how to judge when the benefit from achieve smaller memory
 requirements for SPARSEMEM
is worth with the additional shift and load when fetching the memory
section.?

"The patch attempts isolates the implementation details of the physical
layout of the sparsemem section
 array."

but how it isolates?

3. sparsemem vmemmap

1)
 The two key operations pfn_to_page and page_to_page become:

    #define __pfn_to_page(pfn)      (vmemmap + (pfn))
    #define __page_to_pfn(page)     ((page) - vmemmap)

how can guarantee the block of memory to be used to back the virtual memory
map is start from vmemmap?

2)
in Documentation/x86/x86_64/mm.txt

Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
hole caused by [48:63] sign extension
ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys.
memory
ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
... unused hole ...
ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from
phys 0
ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space


what's the total memory of the example? why virtual memory map(1TB) is that
big ? then in x86_64 platform 4GB memory, virtual memory map will start
from what address?

Thanks,
Nizhan Chen

[-- Attachment #2: Type: text/html, Size: 3145 bytes --]

             reply	other threads:[~2012-09-25 11:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-25 11:27 ss ss [this message]
2012-09-25 12:58 ` Mel Gorman

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=CAEkdkmVnnCCHvrFzhib_USGQGQYc7UhQjO-nTyp+RLiTXjRtGA@mail.gmail.com \
    --to=nizhan.chen@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bob.picco@hp.com \
    --cc=hannes@cmpxchg.org \
    --cc=haveblue@us.ibm.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=richard@arachsys.com \
    --cc=riel@redhat.com \
    --cc=shli@kernel.org \
    --cc=wency@cn.fujitsu.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