From: Tang Chen <tangchen@cn.fujitsu.com>
To: Simon Jeons <simon.jeons@gmail.com>
Cc: Jianguo Wu <wujianguo@huawei.com>,
akpm@linux-foundation.org, rientjes@google.com,
len.brown@intel.com, benh@kernel.crashing.org, paulus@samba.org,
cl@linux.com, minchan.kim@gmail.com,
kosaki.motohiro@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
wency@cn.fujitsu.com, hpa@zytor.com, linfeng@cn.fujitsu.com,
laijs@cn.fujitsu.com, mgorman@suse.de, yinghai@kernel.org,
glommer@parallels.com, x86@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-acpi@vger.kernel.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, linux-ia64@vger.kernel.org,
cmetcalf@tilera.com, sparclinux@vger.kernel.org
Subject: Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
Date: Fri, 01 Feb 2013 03:39:46 +0000 [thread overview]
Message-ID: <510B3902.6040804@cn.fujitsu.com> (raw)
In-Reply-To: <1359687985.1303.15.camel@kernel>
Hi Simon,
On 02/01/2013 11:06 AM, Simon Jeons wrote:
>
> How can distinguish map and use? I mean how can confirm memory is used
> by kernel instead of map?
If the page is free, for example, it is in the buddy system, it is not
in use.
Even if it is direct mapped by kernel, the kernel logic should not to
access it
because you didn't allocate it. This is the kernel's logic. Of course
the hardware
and the user will not know this.
You want to access some memory, you should first have a logic address,
right?
So how can you get a logic address ? You call alloc api.
For example, when you are coding, of course you write:
p = alloc_xxx(); ---- allocate memory, now, it is in use, alloc_xxx()
makes kernel know it.
*p = ...... ---- use the memory
You won't write:
p = 0xFFFF8745; ---- if so, kernel doesn't know it is in use
*p = ...... ---- wrong...
right ?
The kernel mapped a page, it doesn't mean it is using the page. You
should allocate it.
That is just the kernel's allocating logic.
Well, I think I can only give you this answer now. If you want something
deeper, I think
you need to read how the kernel manage the physical pages. :)
>
> 1) If user process and kenel map to same physical memory, user process
> will get SIGSEGV during #PF if access to this memory, but If user proces
> s will map to the same memory which kernel map? Why? It can't access it.
When you call malloc() to allocate memory in user space, the OS logic will
assure that you won't map a page that has already been used by kernel.
A page is mapped by kernel, but not used by kernel (not allocated, like
above),
malloc() could allocate it, and map it to user space. This is the situation
you are talking about, right ?
Now it is mapped by kernel and user, but it is only allocated by user.
So the kernel
will not use it. When the kernel wants some memory, it will allocate
some other memory.
This is just the kernel logic. This is what memory management subsystem
does.
I think I cannot answer more because I'm also a student in memory
management.
This is just my understanding. And I hope it is helpful. :)
> 2) If two user processes map to same physical memory, what will happen
> if one process access the memory?
Obviously you don't need to worry about this situation. We can swap the page
used by process 1 out, and process 2 can use the same page. When process
1 wants
to access it again, we swap it in. This only happens when the physical
memory
is not enough to use. :)
And also, if you are using shared memory in user space, like
shmget(), shmat()......
it is the shared memory, both processes can use it at the same time.
Thanks. :)
prev parent reply other threads:[~2013-02-01 3:39 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 9:32 [PATCH v6 00/15] memory-hotplug: hot-remove physical memory Tang Chen
2013-01-09 9:32 ` [PATCH v6 01/15] memory-hotplug: try to offline the memory twice to avoid dependence Tang Chen
2013-01-09 9:32 ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing m Tang Chen
2013-01-09 23:11 ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removi Andrew Morton
2013-01-10 5:56 ` Tang Chen
2013-01-09 9:32 ` [PATCH v6 03/15] memory-hotplug: remove redundant codes Tang Chen
2013-01-09 9:32 ` [PATCH v6 04/15] memory-hotplug: remove /sys/firmware/memmap/X sysfs Tang Chen
2013-01-09 22:49 ` Andrew Morton
2013-01-10 6:07 ` Tang Chen
2013-01-09 23:19 ` Andrew Morton
2013-01-10 6:15 ` Tang Chen
2013-01-09 9:32 ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page table Tang Chen
2013-01-09 22:50 ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page t Andrew Morton
2013-01-10 2:25 ` Tang Chen
2013-01-09 9:32 ` [PATCH v6 06/15] memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap Tang Chen
2013-01-09 9:32 ` [PATCH v6 07/15] memory-hotplug: move pgdat_resize_lock into sparse_remove_one_section() Tang Chen
2013-01-09 9:32 ` [PATCH v6 08/15] memory-hotplug: Common APIs to support page tables hot-remove Tang Chen
2013-01-29 13:02 ` Simon Jeons
2013-01-30 1:53 ` Jianguo Wu
2013-01-30 2:13 ` Simon Jeons
2013-01-29 13:04 ` Simon Jeons
2013-01-30 2:16 ` Tang Chen
2013-01-30 3:27 ` Simon Jeons
2013-01-30 5:55 ` Tang Chen
2013-01-30 7:32 ` Simon Jeons
2013-02-04 23:04 ` Andrew Morton
2013-01-09 9:32 ` [PATCH v6 09/15] memory-hotplug: remove page table of x86_64 architecture Tang Chen
2013-01-09 9:32 ` [PATCH v6 10/15] memory-hotplug: remove memmap of sparse-vmemmap Tang Chen
2013-01-09 9:32 ` [PATCH v6 11/15] memory-hotplug: Integrated __remove_section() of CONFIG_SPARSEMEM_VMEMMAP Tang Chen
2013-01-09 9:32 ` [PATCH v6 12/15] memory-hotplug: memory_hotplug: clear zone when removing the memory Tang Chen
2013-01-09 9:32 ` [PATCH v6 13/15] memory-hotplug: remove sysfs file of node Tang Chen
2013-01-09 9:32 ` [PATCH v6 14/15] memory-hotplug: free node_data when a node is offlined Tang Chen
2013-01-09 9:32 ` [PATCH v6 15/15] memory-hotplug: Do not allocate pdgat if it was not freed when offline Tang Chen
2013-01-09 22:23 ` [PATCH v6 00/15] memory-hotplug: hot-remove physical memory Andrew Morton
2013-01-10 2:17 ` Tang Chen
2013-01-10 7:14 ` Glauber Costa
2013-01-10 7:31 ` Kamezawa Hiroyuki
2013-01-10 7:55 ` Glauber Costa
2013-01-10 8:23 ` Kamezawa Hiroyuki
2013-01-10 8:36 ` Glauber Costa
2013-01-10 8:39 ` Kamezawa Hiroyuki
2013-01-09 23:33 ` Andrew Morton
2013-01-10 2:18 ` Tang Chen
2013-01-29 12:52 ` Simon Jeons
2013-01-30 2:32 ` Tang Chen
2013-01-30 2:48 ` Simon Jeons
2013-01-30 3:00 ` Tang Chen
2013-01-30 10:15 ` Tang Chen
2013-01-30 10:18 ` Tang Chen
2013-01-31 1:22 ` Simon Jeons
2013-01-31 3:31 ` Tang Chen
2013-01-31 6:19 ` Simon Jeons
2013-01-31 7:10 ` Tang Chen
2013-01-31 8:17 ` Simon Jeons
2013-01-31 8:48 ` Simon Jeons
2013-01-31 9:44 ` Tang Chen
2013-01-31 10:38 ` Simon Jeons
2013-02-01 1:32 ` Jianguo Wu
2013-02-01 1:36 ` Simon Jeons
2013-02-01 1:57 ` Jianguo Wu
2013-02-01 2:06 ` Simon Jeons
2013-02-01 2:18 ` Jianguo Wu
2013-02-01 1:57 ` Tang Chen
2013-02-01 2:17 ` Simon Jeons
2013-02-01 2:42 ` Tang Chen
2013-02-01 3:06 ` Simon Jeons
2013-02-01 3:39 ` Tang Chen [this message]
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=510B3902.6040804@cn.fujitsu.com \
--to=tangchen@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux.com \
--cc=cmetcalf@tilera.com \
--cc=glommer@parallels.com \
--cc=hpa@zytor.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linfeng@cn.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@suse.de \
--cc=minchan.kim@gmail.com \
--cc=paulus@samba.org \
--cc=rientjes@google.com \
--cc=simon.jeons@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=wency@cn.fujitsu.com \
--cc=wujianguo@huawei.com \
--cc=x86@kernel.org \
--cc=yinghai@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).