From: Yasunori Goto <y-goto@jp.fujitsu.com>
To: Linux Kernel ML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Cc: Andrew Morton <akpm@osdl.org>,
Christoph Lameter <clameter@sgi.com>, Mel Gorman <mel@csn.ul.ie>
Subject: [RFC] memory hotremove patch take 2 [00/10]
Date: Wed, 09 May 2007 11:59:38 +0900 [thread overview]
Message-ID: <20070509115506.B904.Y-GOTO@jp.fujitsu.com> (raw)
Hello.
I rebased and debugged Kame-san's memory hot-remove patches.
This work is not finished yet. (Some pages keep un-removable status)
But, I would like to show current progress of it, because it has
been a long time since previous post, and some bugs are fixed.
If you have concern, please check this. Any comments are welcome.
Thanks.
---
These patches are for memory hot-remove.
How to use
- kernelcore=xx[GMK] must be specified at boottime option to create
ZONE_MOVABLE area.
- After bootup, execute following.
# echo "offline" > /sys/devices/system/memory/memoryX/status
Change log from previous version.
- Rebase to 2.6.21-mm1.
- Old original ZONE_MOVABLE code is removed. Mel-san's ZONE_REMOVABLE
for anti-fragmentation is used.
- Fix wrong return code check of isolate_lru_page()
- Page is isolated ASAP, which was source of page migration when
memory-hotremove. In old code, it uses just put_page(),
and we expected that migrated source page is catched in
__free_one_page() as isolated page. But, it is spooled in
per_cpu_page and used soon for next destination page of migration.
This was cause of eternal loop in offline_pages().
- There is a page which is not mapped but added to swapcache in
swap-in code. It was cause of panic in try_to_unmap(). fixed it.
- end_pfn is rounded up at memmap_init. If there is a small hole on
end of section. These page is not initialized.
TODO:
- There are some pages which are un-removable page on memory stress
condition. (These pages are set PG_swapcache or PG_mappedtodisk
without connecting to lru.)
- Should make i386/x86-64/powerpc interface code. But not yet
(really sorry :-( ).
- If bootmem parameter or efi's memory map is stored by efi, memory
can't be removed even if it is in removable zone.
- node hotplug support. (this may needs some amount of patches.)
- test under heavy work load and more careful race check.
- Fix where we should allocate migration target page from.
- Hmmmm.... And so on.
[1] counters patch -- per-zone counter for ZONE_MOVABLE
==page isolation==
[2] page isolation patch ..... basic defintions of page isolation.
[3] drain_all_zone_pages patch ..... drain all cpus' pcp pages.
[4] isolate freed page patch ..... isolate pages in free_area[]
==memory unplug==
offline a section of pages. isolate specified section and migrate
content of used pages to out of section. (Because free pages in a
section is isolated, it never be returned by alloc_pages())
This patch doesn't care where we should allocate migration new pages from.
[5] memory unplug core patch --- maybe need more work.
[6] interface patch --- "offline" interface support
==migration nocontext==
Fix race condition of page migration without process context
(not taking mm->sem). This patch delayes kmem_cache_free() of
anon_vma until migration ends.
[7] migration nocontext patch --- support page migration without
acquiring mm->sem. need careful debug...
==other fixes==
[8] round up end_pfn at memmap_init
[9] page isolation ASAP when memory-hotremove case.
[10] fix swapping-in page panic.
--
Yasunori Goto
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2007-05-09 2:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-09 2:59 Yasunori Goto [this message]
2007-05-09 3:10 ` [RFC] memory hotremove patch take 2 [01/10] (counter of removable page) Yasunori Goto
2007-05-10 12:46 ` Mel Gorman
2007-05-10 13:44 ` Andi Kleen
2007-05-11 1:08 ` KAMEZAWA Hiroyuki
2007-05-10 18:00 ` Christoph Lameter
2007-05-11 1:09 ` KAMEZAWA Hiroyuki
2007-05-09 3:10 ` [RFC] memory hotremove patch take 2 [02/10] (make page unused) Yasunori Goto
2007-05-10 15:34 ` Mel Gorman
2007-05-11 0:47 ` KAMEZAWA Hiroyuki
2007-05-10 18:04 ` Christoph Lameter
2007-05-11 0:49 ` KAMEZAWA Hiroyuki
2007-05-09 3:10 ` [RFC] memory hotremove patch take 2 [03/10] (drain all pages) Yasunori Goto
2007-05-10 15:35 ` Mel Gorman
2007-05-11 0:53 ` KAMEZAWA Hiroyuki
2007-05-10 18:07 ` Christoph Lameter
2007-05-11 0:54 ` KAMEZAWA Hiroyuki
2007-05-09 3:10 ` [RFC] memory hotremove patch take 2 [04/10] (isolate all free pages) Yasunori Goto
2007-05-10 16:42 ` Mel Gorman
2007-05-11 0:58 ` KAMEZAWA Hiroyuki
2007-05-10 18:07 ` Christoph Lameter
2007-05-09 3:11 ` [RFC] memory hotremove patch take 2 [05/10] (make basic remove code) Yasunori Goto
2007-05-10 18:09 ` Christoph Lameter
2007-05-11 1:05 ` KAMEZAWA Hiroyuki
2007-05-09 3:11 ` [RFC] memory hotremove patch take 2 [06/10] (ia64's remove_memory code) Yasunori Goto
2007-05-09 3:11 ` [RFC] memory hotremove patch take 2 [07/10] (delay freeing anon_vma) Yasunori Goto
2007-05-09 3:12 ` [RFC] memory hotremove patch take 2 [08/10] (memap init alignment) Yasunori Goto
2007-05-09 3:12 ` [RFC] memory hotremove patch take 2 [09/10] (direct isolation for remove) Yasunori Goto
2007-05-09 3:12 ` [RFC] memory hotremove patch take 2 [10/10] (retry swap-in page) Yasunori Goto
2007-05-09 3:26 ` KAMEZAWA Hiroyuki
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=20070509115506.B904.Y-GOTO@jp.fujitsu.com \
--to=y-goto@jp.fujitsu.com \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/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