* [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-22 11:42 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:42 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
Here are some bug fix patches for physical memory hot-remove. All these
patches are based on the latest -mm tree.
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
And patch1 and patch3 are very important.
patch1: free compound pages when freeing memmap, otherwise the kernel
will panic the next time memory is hot-added.
patch3: the old way of freeing pagetable pages was wrong. We should never
split larger pages into small ones.
Lai Jiangshan (1):
Bug-fix: mempolicy: fix is_valid_nodemask()
Tang Chen (3):
Bug fix: Do not split pages when freeing pagetable pages.
Bug fix: Fix section mismatch problem of
release_firmware_map_entry().
Bug fix: Fix the doc format in drivers/firmware/memmap.c
Wen Congyang (1):
Bug fix: consider compound pages when free memmap
arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
drivers/firmware/memmap.c | 16 +++---
mm/mempolicy.c | 36 +++++++----
mm/sparse.c | 2 +-
4 files changed, 77 insertions(+), 125 deletions(-)
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-22 11:42 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:42 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: linux-mm, x86, linuxppc-dev, linux-kernel, linux-acpi
Here are some bug fix patches for physical memory hot-remove. All these
patches are based on the latest -mm tree.
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
And patch1 and patch3 are very important.
patch1: free compound pages when freeing memmap, otherwise the kernel
will panic the next time memory is hot-added.
patch3: the old way of freeing pagetable pages was wrong. We should never
split larger pages into small ones.
Lai Jiangshan (1):
Bug-fix: mempolicy: fix is_valid_nodemask()
Tang Chen (3):
Bug fix: Do not split pages when freeing pagetable pages.
Bug fix: Fix section mismatch problem of
release_firmware_map_entry().
Bug fix: Fix the doc format in drivers/firmware/memmap.c
Wen Congyang (1):
Bug fix: consider compound pages when free memmap
arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
drivers/firmware/memmap.c | 16 +++---
mm/mempolicy.c | 36 +++++++----
mm/sparse.c | 2 +-
4 files changed, 77 insertions(+), 125 deletions(-)
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH Bug fix 1/5] Bug fix: consider compound pages when free memmap
2013-01-22 11:42 ` Tang Chen
(?)
@ 2013-01-22 11:43 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
From: Wen Congyang <wency@cn.fujitsu.com>
usemap could also be allocated as compound pages. Should also
consider compound pages when freeing memmap.
If we don't fix it, there could be problems when we free vmemmap
pagetables which are stored in compound pages. The old pagetables
will not be freed properly, and when we add the memory again,
no new pagetable will be created. And the old pagetable entry is
used, than the kernel will panic.
The call trace is like the following:
[ 691.175487] BUG: unable to handle kernel paging request at ffffea0040000000
[ 691.258872] IP: [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 691.336971] PGD 7ff7d4067 PUD 78e035067 PMD 78e11d067 PTE 0
[ 691.403952] Oops: 0002 [#1] SMP
[ 691.442695] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc sunrpc binfmt_misc dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel microcode pcspkr sg lpc_ich mfd_core i2c_i801 i2c_core i7core_edac edac_core ioatdma e1000e igb dca ptp pps_core sd_mod crc_t10dif megaraid_sas mptsas mptscsih mptbase scsi_transport_sas scsi_mod
[ 692.042726] CPU 0
[ 692.064641] Pid: 4, comm: kworker/0:0 Tainted: G W 3.8.0-rc3-phy-hot-remove+ #3 FUJITSU-SV PRIMEQUEST 1800E/SB
[ 692.196723] RIP: 0010:[<ffffffff816a483f>] [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 692.303885] RSP: 0018:ffff8807bdcb35d8 EFLAGS: 00010006
[ 692.367331] RAX: 0000000000000000 RBX: 0000000000000200 RCX: 0000000000200000
[ 692.452578] RDX: ffff88078df01148 RSI: 0000000000000282 RDI: ffffea0040000000
[ 692.537822] RBP: ffff8807bdcb3618 R08: 4cf05005b019467a R09: 0cd98fa09631467a
[ 692.623071] R10: 0000000000000000 R11: 0000000000030e20 R12: 0000000000008000
[ 692.708319] R13: ffffea0040000000 R14: ffff88078df66248 R15: ffff88078ea13b10
[ 692.793562] FS: 0000000000000000(0000) GS:ffff8807c1a00000(0000) knlGS:0000000000000000
[ 692.890233] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 692.958870] CR2: ffffea0040000000 CR3: 0000000001c0c000 CR4: 00000000000007f0
[ 693.044119] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 693.129367] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 693.214617] Process kworker/0:0 (pid: 4, threadinfo ffff8807bdcb2000, task ffff8807bde18000)
[ 693.315437] Stack:
[ 693.339421] 0000000000000000 0000000000000282 0000000000000000 ffff88078df40f00
[ 693.428208] 0000000000000001 0000000000000200 00000000000002ff 0000000000000200
[ 693.516981] ffff8807bdcb3668 ffffffff816940e5 0000000000000000 0000000001000000
[ 693.605761] Call Trace:
[ 693.634949] [<ffffffff816940e5>] __add_pages+0x85/0x120
[ 693.698398] [<ffffffff8104f1d1>] arch_add_memory+0x71/0xf0
[ 693.764960] [<ffffffff81079bff>] ? request_resource_conflict+0x8f/0xa0
[ 693.843982] [<ffffffff81694796>] add_memory+0xd6/0x1f0
[ 693.906393] [<ffffffff814044df>] acpi_memory_device_add+0x170/0x20c
[ 693.982302] [<ffffffff813c1de2>] acpi_device_probe+0x50/0x18a
[ 694.051977] [<ffffffff8125a9d3>] ? sysfs_create_link+0x13/0x20
[ 694.122691] [<ffffffff8146c31c>] really_probe+0x6c/0x320
[ 694.187170] [<ffffffff8146c617>] driver_probe_device+0x47/0xa0
[ 694.257885] [<ffffffff8146c720>] ? __driver_attach+0xb0/0xb0
[ 694.326521] [<ffffffff8146c720>] ? __driver_attach+0xb0/0xb0
[ 694.395157] [<ffffffff8146c773>] __device_attach+0x53/0x60
[ 694.461719] [<ffffffff8146a34c>] bus_for_each_drv+0x6c/0xa0
[ 694.529316] [<ffffffff8146c298>] device_attach+0xa8/0xc0
[ 694.593799] [<ffffffff8146af70>] bus_probe_device+0xb0/0xe0
[ 694.661398] [<ffffffff814699c1>] device_add+0x301/0x570
[ 694.724842] [<ffffffff81469c4e>] device_register+0x1e/0x30
[ 694.791403] [<ffffffff813c354a>] acpi_device_register+0x1d8/0x27c
[ 694.865230] [<ffffffff813c37cd>] acpi_add_single_object+0x1df/0x2b9
[ 694.941140] [<ffffffff813fa078>] ? acpi_ut_release_mutex+0xac/0xb5
[ 695.016009] [<ffffffff813c39b9>] acpi_bus_check_add+0x112/0x18f
[ 695.087764] [<ffffffff810df61d>] ? trace_hardirqs_on+0xd/0x10
[ 695.157445] [<ffffffff810a1b0f>] ? up+0x2f/0x50
[ 695.212585] [<ffffffff813bdddb>] ? acpi_os_signal_semaphore+0x6b/0x74
[ 695.290573] [<ffffffff813ec519>] acpi_ns_walk_namespace+0x105/0x255
[ 695.366478] [<ffffffff813c38a7>] ? acpi_add_single_object+0x2b9/0x2b9
[ 695.444459] [<ffffffff813c38a7>] ? acpi_add_single_object+0x2b9/0x2b9
[ 695.522439] [<ffffffff813ecb6c>] acpi_walk_namespace+0xcf/0x118
[ 695.594190] [<ffffffff813c3a91>] acpi_bus_scan+0x5b/0x7c
[ 695.658676] [<ffffffff813c3b1e>] acpi_bus_add+0x2a/0x2c
[ 695.722121] [<ffffffff81402905>] container_notify_cb+0x112/0x1a9
[ 695.794914] [<ffffffff813d5859>] acpi_ev_notify_dispatch+0x46/0x61
[ 695.869781] [<ffffffff813be072>] acpi_os_execute_deferred+0x27/0x34
[ 695.945687] [<ffffffff81091c6e>] process_one_work+0x20e/0x5c0
[ 696.015361] [<ffffffff81091bff>] ? process_one_work+0x19f/0x5c0
[ 696.087113] [<ffffffff813be04b>] ? acpi_os_wait_events_complete+0x23/0x23
[ 696.169248] [<ffffffff81093d0e>] worker_thread+0x12e/0x370
[ 696.235807] [<ffffffff81093be0>] ? manage_workers+0x180/0x180
[ 696.305485] [<ffffffff81099e4e>] kthread+0xee/0x100
[ 696.364773] [<ffffffff810e1179>] ? __lock_release+0x129/0x190
[ 696.434450] [<ffffffff81099d60>] ? __init_kthread_worker+0x70/0x70
[ 696.509317] [<ffffffff816b34ac>] ret_from_fork+0x7c/0xb0
[ 696.573799] [<ffffffff81099d60>] ? __init_kthread_worker+0x70/0x70
[ 696.648662] Code: 00 00 48 89 df 48 89 45 c8 e8 3e 71 b1 ff 48 89 c2 48 8b 75 c8 b8 ef ff ff ff f6 02 01 75 4b 49 63 cc 31 c0 4c 89 ef 48 c1 e1 06 <f3> aa 48 8b 02 48 83 c8 01 48 85 d2 48 89 02 74 29 a8 01 74 25
[ 696.880997] RIP [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 696.960128] RSP <ffff8807bdcb35d8>
[ 697.001768] CR2: ffffea0040000000
[ 697.041336] ---[ end trace e7f94e3a34c442d4 ]---
[ 697.096474] Kernel panic - not syncing: Fatal exception
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
mm/sparse.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index ef29496..7ca6dc8 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -698,7 +698,7 @@ static void free_section_usemap(struct page *memmap, unsigned long *usemap)
/*
* Check to see if allocation came from hot-plug-add
*/
- if (PageSlab(usemap_page)) {
+ if (PageSlab(usemap_page) || PageCompound(usemap_page)) {
kfree(usemap);
if (memmap)
__kfree_section_memmap(memmap, PAGES_PER_SECTION);
--
1.7.1
--
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>
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 1/5] Bug fix: consider compound pages when free memmap
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
From: Wen Congyang <wency@cn.fujitsu.com>
usemap could also be allocated as compound pages. Should also
consider compound pages when freeing memmap.
If we don't fix it, there could be problems when we free vmemmap
pagetables which are stored in compound pages. The old pagetables
will not be freed properly, and when we add the memory again,
no new pagetable will be created. And the old pagetable entry is
used, than the kernel will panic.
The call trace is like the following:
[ 691.175487] BUG: unable to handle kernel paging request at ffffea0040000000
[ 691.258872] IP: [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 691.336971] PGD 7ff7d4067 PUD 78e035067 PMD 78e11d067 PTE 0
[ 691.403952] Oops: 0002 [#1] SMP
[ 691.442695] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc sunrpc binfmt_misc dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel microcode pcspkr sg lpc_ich mfd_core i2c_i801 i2c_core i7core_edac edac_core ioatdma e1000e igb dca ptp pps_core sd_mod crc_t10dif megaraid_sas mptsas mptscsih mptbase scsi_transport_sas scsi_mod
[ 692.042726] CPU 0
[ 692.064641] Pid: 4, comm: kworker/0:0 Tainted: G W 3.8.0-rc3-phy-hot-remove+ #3 FUJITSU-SV PRIMEQUEST 1800E/SB
[ 692.196723] RIP: 0010:[<ffffffff816a483f>] [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 692.303885] RSP: 0018:ffff8807bdcb35d8 EFLAGS: 00010006
[ 692.367331] RAX: 0000000000000000 RBX: 0000000000000200 RCX: 0000000000200000
[ 692.452578] RDX: ffff88078df01148 RSI: 0000000000000282 RDI: ffffea0040000000
[ 692.537822] RBP: ffff8807bdcb3618 R08: 4cf05005b019467a R09: 0cd98fa09631467a
[ 692.623071] R10: 0000000000000000 R11: 0000000000030e20 R12: 0000000000008000
[ 692.708319] R13: ffffea0040000000 R14: ffff88078df66248 R15: ffff88078ea13b10
[ 692.793562] FS: 0000000000000000(0000) GS:ffff8807c1a00000(0000) knlGS:0000000000000000
[ 692.890233] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 692.958870] CR2: ffffea0040000000 CR3: 0000000001c0c000 CR4: 00000000000007f0
[ 693.044119] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 693.129367] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 693.214617] Process kworker/0:0 (pid: 4, threadinfo ffff8807bdcb2000, task ffff8807bde18000)
[ 693.315437] Stack:
[ 693.339421] 0000000000000000 0000000000000282 0000000000000000 ffff88078df40f00
[ 693.428208] 0000000000000001 0000000000000200 00000000000002ff 0000000000000200
[ 693.516981] ffff8807bdcb3668 ffffffff816940e5 0000000000000000 0000000001000000
[ 693.605761] Call Trace:
[ 693.634949] [<ffffffff816940e5>] __add_pages+0x85/0x120
[ 693.698398] [<ffffffff8104f1d1>] arch_add_memory+0x71/0xf0
[ 693.764960] [<ffffffff81079bff>] ? request_resource_conflict+0x8f/0xa0
[ 693.843982] [<ffffffff81694796>] add_memory+0xd6/0x1f0
[ 693.906393] [<ffffffff814044df>] acpi_memory_device_add+0x170/0x20c
[ 693.982302] [<ffffffff813c1de2>] acpi_device_probe+0x50/0x18a
[ 694.051977] [<ffffffff8125a9d3>] ? sysfs_create_link+0x13/0x20
[ 694.122691] [<ffffffff8146c31c>] really_probe+0x6c/0x320
[ 694.187170] [<ffffffff8146c617>] driver_probe_device+0x47/0xa0
[ 694.257885] [<ffffffff8146c720>] ? __driver_attach+0xb0/0xb0
[ 694.326521] [<ffffffff8146c720>] ? __driver_attach+0xb0/0xb0
[ 694.395157] [<ffffffff8146c773>] __device_attach+0x53/0x60
[ 694.461719] [<ffffffff8146a34c>] bus_for_each_drv+0x6c/0xa0
[ 694.529316] [<ffffffff8146c298>] device_attach+0xa8/0xc0
[ 694.593799] [<ffffffff8146af70>] bus_probe_device+0xb0/0xe0
[ 694.661398] [<ffffffff814699c1>] device_add+0x301/0x570
[ 694.724842] [<ffffffff81469c4e>] device_register+0x1e/0x30
[ 694.791403] [<ffffffff813c354a>] acpi_device_register+0x1d8/0x27c
[ 694.865230] [<ffffffff813c37cd>] acpi_add_single_object+0x1df/0x2b9
[ 694.941140] [<ffffffff813fa078>] ? acpi_ut_release_mutex+0xac/0xb5
[ 695.016009] [<ffffffff813c39b9>] acpi_bus_check_add+0x112/0x18f
[ 695.087764] [<ffffffff810df61d>] ? trace_hardirqs_on+0xd/0x10
[ 695.157445] [<ffffffff810a1b0f>] ? up+0x2f/0x50
[ 695.212585] [<ffffffff813bdddb>] ? acpi_os_signal_semaphore+0x6b/0x74
[ 695.290573] [<ffffffff813ec519>] acpi_ns_walk_namespace+0x105/0x255
[ 695.366478] [<ffffffff813c38a7>] ? acpi_add_single_object+0x2b9/0x2b9
[ 695.444459] [<ffffffff813c38a7>] ? acpi_add_single_object+0x2b9/0x2b9
[ 695.522439] [<ffffffff813ecb6c>] acpi_walk_namespace+0xcf/0x118
[ 695.594190] [<ffffffff813c3a91>] acpi_bus_scan+0x5b/0x7c
[ 695.658676] [<ffffffff813c3b1e>] acpi_bus_add+0x2a/0x2c
[ 695.722121] [<ffffffff81402905>] container_notify_cb+0x112/0x1a9
[ 695.794914] [<ffffffff813d5859>] acpi_ev_notify_dispatch+0x46/0x61
[ 695.869781] [<ffffffff813be072>] acpi_os_execute_deferred+0x27/0x34
[ 695.945687] [<ffffffff81091c6e>] process_one_work+0x20e/0x5c0
[ 696.015361] [<ffffffff81091bff>] ? process_one_work+0x19f/0x5c0
[ 696.087113] [<ffffffff813be04b>] ? acpi_os_wait_events_complete+0x23/0x23
[ 696.169248] [<ffffffff81093d0e>] worker_thread+0x12e/0x370
[ 696.235807] [<ffffffff81093be0>] ? manage_workers+0x180/0x180
[ 696.305485] [<ffffffff81099e4e>] kthread+0xee/0x100
[ 696.364773] [<ffffffff810e1179>] ? __lock_release+0x129/0x190
[ 696.434450] [<ffffffff81099d60>] ? __init_kthread_worker+0x70/0x70
[ 696.509317] [<ffffffff816b34ac>] ret_from_fork+0x7c/0xb0
[ 696.573799] [<ffffffff81099d60>] ? __init_kthread_worker+0x70/0x70
[ 696.648662] Code: 00 00 48 89 df 48 89 45 c8 e8 3e 71 b1 ff 48 89 c2 48 8b 75 c8 b8 ef ff ff ff f6 02 01 75 4b 49 63 cc 31 c0 4c 89 ef 48 c1 e1 06 <f3> aa 48 8b 02 48 83 c8 01 48 85 d2 48 89 02 74 29 a8 01 74 25
[ 696.880997] RIP [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 696.960128] RSP <ffff8807bdcb35d8>
[ 697.001768] CR2: ffffea0040000000
[ 697.041336] ---[ end trace e7f94e3a34c442d4 ]---
[ 697.096474] Kernel panic - not syncing: Fatal exception
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
mm/sparse.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index ef29496..7ca6dc8 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -698,7 +698,7 @@ static void free_section_usemap(struct page *memmap, unsigned long *usemap)
/*
* Check to see if allocation came from hot-plug-add
*/
- if (PageSlab(usemap_page)) {
+ if (PageSlab(usemap_page) || PageCompound(usemap_page)) {
kfree(usemap);
if (memmap)
__kfree_section_memmap(memmap, PAGES_PER_SECTION);
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 1/5] Bug fix: consider compound pages when free memmap
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: linux-mm, x86, linuxppc-dev, linux-kernel, linux-acpi
From: Wen Congyang <wency@cn.fujitsu.com>
usemap could also be allocated as compound pages. Should also
consider compound pages when freeing memmap.
If we don't fix it, there could be problems when we free vmemmap
pagetables which are stored in compound pages. The old pagetables
will not be freed properly, and when we add the memory again,
no new pagetable will be created. And the old pagetable entry is
used, than the kernel will panic.
The call trace is like the following:
[ 691.175487] BUG: unable to handle kernel paging request at ffffea0040000000
[ 691.258872] IP: [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 691.336971] PGD 7ff7d4067 PUD 78e035067 PMD 78e11d067 PTE 0
[ 691.403952] Oops: 0002 [#1] SMP
[ 691.442695] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc sunrpc binfmt_misc dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel microcode pcspkr sg lpc_ich mfd_core i2c_i801 i2c_core i7core_edac edac_core ioatdma e1000e igb dca ptp pps_core sd_mod crc_t10dif megaraid_sas mptsas mptscsih mptbase scsi_transport_sas scsi_mod
[ 692.042726] CPU 0
[ 692.064641] Pid: 4, comm: kworker/0:0 Tainted: G W 3.8.0-rc3-phy-hot-remove+ #3 FUJITSU-SV PRIMEQUEST 1800E/SB
[ 692.196723] RIP: 0010:[<ffffffff816a483f>] [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 692.303885] RSP: 0018:ffff8807bdcb35d8 EFLAGS: 00010006
[ 692.367331] RAX: 0000000000000000 RBX: 0000000000000200 RCX: 0000000000200000
[ 692.452578] RDX: ffff88078df01148 RSI: 0000000000000282 RDI: ffffea0040000000
[ 692.537822] RBP: ffff8807bdcb3618 R08: 4cf05005b019467a R09: 0cd98fa09631467a
[ 692.623071] R10: 0000000000000000 R11: 0000000000030e20 R12: 0000000000008000
[ 692.708319] R13: ffffea0040000000 R14: ffff88078df66248 R15: ffff88078ea13b10
[ 692.793562] FS: 0000000000000000(0000) GS:ffff8807c1a00000(0000) knlGS:0000000000000000
[ 692.890233] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 692.958870] CR2: ffffea0040000000 CR3: 0000000001c0c000 CR4: 00000000000007f0
[ 693.044119] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 693.129367] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 693.214617] Process kworker/0:0 (pid: 4, threadinfo ffff8807bdcb2000, task ffff8807bde18000)
[ 693.315437] Stack:
[ 693.339421] 0000000000000000 0000000000000282 0000000000000000 ffff88078df40f00
[ 693.428208] 0000000000000001 0000000000000200 00000000000002ff 0000000000000200
[ 693.516981] ffff8807bdcb3668 ffffffff816940e5 0000000000000000 0000000001000000
[ 693.605761] Call Trace:
[ 693.634949] [<ffffffff816940e5>] __add_pages+0x85/0x120
[ 693.698398] [<ffffffff8104f1d1>] arch_add_memory+0x71/0xf0
[ 693.764960] [<ffffffff81079bff>] ? request_resource_conflict+0x8f/0xa0
[ 693.843982] [<ffffffff81694796>] add_memory+0xd6/0x1f0
[ 693.906393] [<ffffffff814044df>] acpi_memory_device_add+0x170/0x20c
[ 693.982302] [<ffffffff813c1de2>] acpi_device_probe+0x50/0x18a
[ 694.051977] [<ffffffff8125a9d3>] ? sysfs_create_link+0x13/0x20
[ 694.122691] [<ffffffff8146c31c>] really_probe+0x6c/0x320
[ 694.187170] [<ffffffff8146c617>] driver_probe_device+0x47/0xa0
[ 694.257885] [<ffffffff8146c720>] ? __driver_attach+0xb0/0xb0
[ 694.326521] [<ffffffff8146c720>] ? __driver_attach+0xb0/0xb0
[ 694.395157] [<ffffffff8146c773>] __device_attach+0x53/0x60
[ 694.461719] [<ffffffff8146a34c>] bus_for_each_drv+0x6c/0xa0
[ 694.529316] [<ffffffff8146c298>] device_attach+0xa8/0xc0
[ 694.593799] [<ffffffff8146af70>] bus_probe_device+0xb0/0xe0
[ 694.661398] [<ffffffff814699c1>] device_add+0x301/0x570
[ 694.724842] [<ffffffff81469c4e>] device_register+0x1e/0x30
[ 694.791403] [<ffffffff813c354a>] acpi_device_register+0x1d8/0x27c
[ 694.865230] [<ffffffff813c37cd>] acpi_add_single_object+0x1df/0x2b9
[ 694.941140] [<ffffffff813fa078>] ? acpi_ut_release_mutex+0xac/0xb5
[ 695.016009] [<ffffffff813c39b9>] acpi_bus_check_add+0x112/0x18f
[ 695.087764] [<ffffffff810df61d>] ? trace_hardirqs_on+0xd/0x10
[ 695.157445] [<ffffffff810a1b0f>] ? up+0x2f/0x50
[ 695.212585] [<ffffffff813bdddb>] ? acpi_os_signal_semaphore+0x6b/0x74
[ 695.290573] [<ffffffff813ec519>] acpi_ns_walk_namespace+0x105/0x255
[ 695.366478] [<ffffffff813c38a7>] ? acpi_add_single_object+0x2b9/0x2b9
[ 695.444459] [<ffffffff813c38a7>] ? acpi_add_single_object+0x2b9/0x2b9
[ 695.522439] [<ffffffff813ecb6c>] acpi_walk_namespace+0xcf/0x118
[ 695.594190] [<ffffffff813c3a91>] acpi_bus_scan+0x5b/0x7c
[ 695.658676] [<ffffffff813c3b1e>] acpi_bus_add+0x2a/0x2c
[ 695.722121] [<ffffffff81402905>] container_notify_cb+0x112/0x1a9
[ 695.794914] [<ffffffff813d5859>] acpi_ev_notify_dispatch+0x46/0x61
[ 695.869781] [<ffffffff813be072>] acpi_os_execute_deferred+0x27/0x34
[ 695.945687] [<ffffffff81091c6e>] process_one_work+0x20e/0x5c0
[ 696.015361] [<ffffffff81091bff>] ? process_one_work+0x19f/0x5c0
[ 696.087113] [<ffffffff813be04b>] ? acpi_os_wait_events_complete+0x23/0x23
[ 696.169248] [<ffffffff81093d0e>] worker_thread+0x12e/0x370
[ 696.235807] [<ffffffff81093be0>] ? manage_workers+0x180/0x180
[ 696.305485] [<ffffffff81099e4e>] kthread+0xee/0x100
[ 696.364773] [<ffffffff810e1179>] ? __lock_release+0x129/0x190
[ 696.434450] [<ffffffff81099d60>] ? __init_kthread_worker+0x70/0x70
[ 696.509317] [<ffffffff816b34ac>] ret_from_fork+0x7c/0xb0
[ 696.573799] [<ffffffff81099d60>] ? __init_kthread_worker+0x70/0x70
[ 696.648662] Code: 00 00 48 89 df 48 89 45 c8 e8 3e 71 b1 ff 48 89 c2 48 8b 75 c8 b8 ef ff ff ff f6 02 01 75 4b 49 63 cc 31 c0 4c 89 ef 48 c1 e1 06 <f3> aa 48 8b 02 48 83 c8 01 48 85 d2 48 89 02 74 29 a8 01 74 25
[ 696.880997] RIP [<ffffffff816a483f>] sparse_add_one_section+0xef/0x166
[ 696.960128] RSP <ffff8807bdcb35d8>
[ 697.001768] CR2: ffffea0040000000
[ 697.041336] ---[ end trace e7f94e3a34c442d4 ]---
[ 697.096474] Kernel panic - not syncing: Fatal exception
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
mm/sparse.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index ef29496..7ca6dc8 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -698,7 +698,7 @@ static void free_section_usemap(struct page *memmap, unsigned long *usemap)
/*
* Check to see if allocation came from hot-plug-add
*/
- if (PageSlab(usemap_page)) {
+ if (PageSlab(usemap_page) || PageCompound(usemap_page)) {
kfree(usemap);
if (memmap)
__kfree_section_memmap(memmap, PAGES_PER_SECTION);
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH Bug fix 2/5] Bug-fix: mempolicy: fix is_valid_nodemask()
2013-01-22 11:42 ` Tang Chen
(?)
@ 2013-01-22 11:43 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
From: Lai Jiangshan <laijs@cn.fujitsu.com>
is_valid_nodemask() is introduced by 19770b32. but it does not match
its comments, because it does not check the zone which > policy_zone.
Also in b377fd, this commits told us, if highest zone is ZONE_MOVABLE,
we should also apply memory policies to it. so ZONE_MOVABLE should be valid zone
for policies. is_valid_nodemask() need to be changed to match it.
Fix: check all zones, even its zoneid > policy_zone.
Use nodes_intersects() instead open code to check it.
Reported-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
mm/mempolicy.c | 36 ++++++++++++++++++++++--------------
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index af8a121..6f7979c 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -161,19 +161,7 @@ static const struct mempolicy_operations {
/* Check that the nodemask contains at least one populated zone */
static int is_valid_nodemask(const nodemask_t *nodemask)
{
- int nd, k;
-
- for_each_node_mask(nd, *nodemask) {
- struct zone *z;
-
- for (k = 0; k <= policy_zone; k++) {
- z = &NODE_DATA(nd)->node_zones[k];
- if (z->managed_pages > 0)
- return 1;
- }
- }
-
- return 0;
+ return nodes_intersects(*nodemask, node_states[N_MEMORY]);
}
static inline int mpol_store_user_nodemask(const struct mempolicy *pol)
@@ -1644,6 +1632,26 @@ struct mempolicy *get_vma_policy(struct task_struct *task,
return pol;
}
+static int apply_policy_zone(struct mempolicy *policy, enum zone_type zone)
+{
+ enum zone_type dynamic_policy_zone = policy_zone;
+
+ BUG_ON(dynamic_policy_zone == ZONE_MOVABLE);
+
+ /*
+ * if policy->v.nodes has movable memory only,
+ * we apply policy when gfp_zone(gfp) = ZONE_MOVABLE only.
+ *
+ * policy->v.nodes is intersect with node_states[N_MEMORY].
+ * so if the following test faile, it implies
+ * policy->v.nodes has movable memory only.
+ */
+ if (!nodes_intersects(policy->v.nodes, node_states[N_HIGH_MEMORY]))
+ dynamic_policy_zone = ZONE_MOVABLE;
+
+ return zone >= dynamic_policy_zone;
+}
+
/*
* Return a nodemask representing a mempolicy for filtering nodes for
* page allocation
@@ -1652,7 +1660,7 @@ static nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy *policy)
{
/* Lower zones don't get a nodemask applied for MPOL_BIND */
if (unlikely(policy->mode == MPOL_BIND) &&
- gfp_zone(gfp) >= policy_zone &&
+ apply_policy_zone(policy, gfp_zone(gfp)) &&
cpuset_nodemask_valid_mems_allowed(&policy->v.nodes))
return &policy->v.nodes;
--
1.7.1
--
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>
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 2/5] Bug-fix: mempolicy: fix is_valid_nodemask()
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
From: Lai Jiangshan <laijs@cn.fujitsu.com>
is_valid_nodemask() is introduced by 19770b32. but it does not match
its comments, because it does not check the zone which > policy_zone.
Also in b377fd, this commits told us, if highest zone is ZONE_MOVABLE,
we should also apply memory policies to it. so ZONE_MOVABLE should be valid zone
for policies. is_valid_nodemask() need to be changed to match it.
Fix: check all zones, even its zoneid > policy_zone.
Use nodes_intersects() instead open code to check it.
Reported-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
mm/mempolicy.c | 36 ++++++++++++++++++++++--------------
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index af8a121..6f7979c 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -161,19 +161,7 @@ static const struct mempolicy_operations {
/* Check that the nodemask contains at least one populated zone */
static int is_valid_nodemask(const nodemask_t *nodemask)
{
- int nd, k;
-
- for_each_node_mask(nd, *nodemask) {
- struct zone *z;
-
- for (k = 0; k <= policy_zone; k++) {
- z = &NODE_DATA(nd)->node_zones[k];
- if (z->managed_pages > 0)
- return 1;
- }
- }
-
- return 0;
+ return nodes_intersects(*nodemask, node_states[N_MEMORY]);
}
static inline int mpol_store_user_nodemask(const struct mempolicy *pol)
@@ -1644,6 +1632,26 @@ struct mempolicy *get_vma_policy(struct task_struct *task,
return pol;
}
+static int apply_policy_zone(struct mempolicy *policy, enum zone_type zone)
+{
+ enum zone_type dynamic_policy_zone = policy_zone;
+
+ BUG_ON(dynamic_policy_zone == ZONE_MOVABLE);
+
+ /*
+ * if policy->v.nodes has movable memory only,
+ * we apply policy when gfp_zone(gfp) = ZONE_MOVABLE only.
+ *
+ * policy->v.nodes is intersect with node_states[N_MEMORY].
+ * so if the following test faile, it implies
+ * policy->v.nodes has movable memory only.
+ */
+ if (!nodes_intersects(policy->v.nodes, node_states[N_HIGH_MEMORY]))
+ dynamic_policy_zone = ZONE_MOVABLE;
+
+ return zone >= dynamic_policy_zone;
+}
+
/*
* Return a nodemask representing a mempolicy for filtering nodes for
* page allocation
@@ -1652,7 +1660,7 @@ static nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy *policy)
{
/* Lower zones don't get a nodemask applied for MPOL_BIND */
if (unlikely(policy->mode == MPOL_BIND) &&
- gfp_zone(gfp) >= policy_zone &&
+ apply_policy_zone(policy, gfp_zone(gfp)) &&
cpuset_nodemask_valid_mems_allowed(&policy->v.nodes))
return &policy->v.nodes;
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 2/5] Bug-fix: mempolicy: fix is_valid_nodemask()
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: linux-mm, x86, linuxppc-dev, linux-kernel, linux-acpi
From: Lai Jiangshan <laijs@cn.fujitsu.com>
is_valid_nodemask() is introduced by 19770b32. but it does not match
its comments, because it does not check the zone which > policy_zone.
Also in b377fd, this commits told us, if highest zone is ZONE_MOVABLE,
we should also apply memory policies to it. so ZONE_MOVABLE should be valid zone
for policies. is_valid_nodemask() need to be changed to match it.
Fix: check all zones, even its zoneid > policy_zone.
Use nodes_intersects() instead open code to check it.
Reported-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
mm/mempolicy.c | 36 ++++++++++++++++++++++--------------
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index af8a121..6f7979c 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -161,19 +161,7 @@ static const struct mempolicy_operations {
/* Check that the nodemask contains at least one populated zone */
static int is_valid_nodemask(const nodemask_t *nodemask)
{
- int nd, k;
-
- for_each_node_mask(nd, *nodemask) {
- struct zone *z;
-
- for (k = 0; k <= policy_zone; k++) {
- z = &NODE_DATA(nd)->node_zones[k];
- if (z->managed_pages > 0)
- return 1;
- }
- }
-
- return 0;
+ return nodes_intersects(*nodemask, node_states[N_MEMORY]);
}
static inline int mpol_store_user_nodemask(const struct mempolicy *pol)
@@ -1644,6 +1632,26 @@ struct mempolicy *get_vma_policy(struct task_struct *task,
return pol;
}
+static int apply_policy_zone(struct mempolicy *policy, enum zone_type zone)
+{
+ enum zone_type dynamic_policy_zone = policy_zone;
+
+ BUG_ON(dynamic_policy_zone == ZONE_MOVABLE);
+
+ /*
+ * if policy->v.nodes has movable memory only,
+ * we apply policy when gfp_zone(gfp) = ZONE_MOVABLE only.
+ *
+ * policy->v.nodes is intersect with node_states[N_MEMORY].
+ * so if the following test faile, it implies
+ * policy->v.nodes has movable memory only.
+ */
+ if (!nodes_intersects(policy->v.nodes, node_states[N_HIGH_MEMORY]))
+ dynamic_policy_zone = ZONE_MOVABLE;
+
+ return zone >= dynamic_policy_zone;
+}
+
/*
* Return a nodemask representing a mempolicy for filtering nodes for
* page allocation
@@ -1652,7 +1660,7 @@ static nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy *policy)
{
/* Lower zones don't get a nodemask applied for MPOL_BIND */
if (unlikely(policy->mode == MPOL_BIND) &&
- gfp_zone(gfp) >= policy_zone &&
+ apply_policy_zone(policy, gfp_zone(gfp)) &&
cpuset_nodemask_valid_mems_allowed(&policy->v.nodes))
return &policy->v.nodes;
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH Bug fix 3/5] Bug fix: Do not split pages when freeing pagetable pages.
2013-01-22 11:42 ` Tang Chen
(?)
@ 2013-01-22 11:43 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
The old way we free pagetable pages was wrong.
The old way is:
When we got a hugepage, we split it into smaller pages. And sometimes,
we only need to free some of the smaller pages because the others are
still in use. And the whole larger page will be freed if all the smaller
pages are not in use. All these were done in remove_pmd/pud_table().
But there is no way to know if the larger page has been split. As a result,
there is no way to decide when to split.
Actually, there is no need to split larger pages into smaller ones.
We do it in the following new way:
1) For direct mapped pages, all the pages were freed when they were offlined.
And since menmory offline is done section by section, all the memory ranges
being removed are aligned to PAGE_SIZE. So only need to deal with unaligned
pages when freeing vmemmap pages.
2) For vmemmap pages being used to store page_struct, if part of the larger
page is still in use, just fill the unused part with 0xFD. And when the
whole page is fulfilled with 0xFD, then free the larger page.
This problem is caused by the following related patch:
memory-hotplug-common-apis-to-support-page-tables-hot-remove.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix.patch
This patch will fix the problem based on the above patches.
Reported-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
arch/x86/mm/init_64.c | 148 +++++++++++++++---------------------------------
1 files changed, 46 insertions(+), 102 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 6d1a768..9fbed24 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -777,7 +777,7 @@ static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
static void __meminit
remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
- bool direct, bool split)
+ bool direct)
{
unsigned long next, pages = 0;
pte_t *pte;
@@ -807,23 +807,9 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
/*
* Do not free direct mapping pages since they were
* freed when offlining, or simplely not in use.
- *
- * Do not free pages split from larger page since only
- * the _count of the 1st page struct is available.
- * Free the larger page when it is fulfilled with 0xFD.
*/
- if (!direct) {
- if (split) {
- /*
- * Fill the split 4KB page with 0xFD.
- * When the whole 2MB page is fulfilled
- * with 0xFD, it could be freed.
- */
- memset((void *)addr, PAGE_INUSE,
- PAGE_SIZE);
- } else
- free_pagetable(pte_page(*pte), 0);
- }
+ if (!direct)
+ free_pagetable(pte_page(*pte), 0);
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
@@ -833,26 +819,24 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
pages++;
} else {
/*
+ * If we are here, we are freeing vmemmap pages since
+ * direct mapped memory ranges to be freed are aligned.
+ *
* If we are not removing the whole page, it means
- * other ptes in this page are being used and we cannot
- * remove them. So fill the unused ptes with 0xFD, and
- * remove the page when it is wholly filled with 0xFD.
+ * other page structs in this page are being used and
+ * we canot remove them. So fill the unused page_structs
+ * with 0xFD, and remove the page when it is wholly
+ * filled with 0xFD.
*/
memset((void *)addr, PAGE_INUSE, next - addr);
- /*
- * If the range is not aligned to PAGE_SIZE, then the
- * page is definitely not split from larger page.
- */
page_addr = page_address(pte_page(*pte));
if (!memchr_inv(page_addr, PAGE_INUSE, PAGE_SIZE)) {
- if (!direct)
- free_pagetable(pte_page(*pte), 0);
+ free_pagetable(pte_page(*pte), 0);
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
spin_unlock(&init_mm.page_table_lock);
- pages++;
}
}
}
@@ -865,13 +849,12 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
static void __meminit
remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
- bool direct, bool split)
+ bool direct)
{
- unsigned long pte_phys, next, pages = 0;
+ unsigned long next, pages = 0;
pte_t *pte_base;
pmd_t *pmd;
void *page_addr;
- bool split_pmd = split, split_pte = false;
pmd = pmd_start + pmd_index(addr);
for (; addr < end; addr = next, pmd++) {
@@ -883,63 +866,35 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
if (pmd_large(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
IS_ALIGNED(next, PMD_SIZE)) {
- if (!direct) {
- if (split_pmd) {
- /*
- * Fill the split 2MB page with
- * 0xFD. When the whole 1GB page
- * is fulfilled with 0xFD, it
- * could be freed.
- */
- memset((void *)addr, PAGE_INUSE,
- PMD_SIZE);
- } else {
- free_pagetable(pmd_page(*pmd),
+ if (!direct)
+ free_pagetable(pmd_page(*pmd),
get_order(PMD_SIZE));
- }
- }
spin_lock(&init_mm.page_table_lock);
pmd_clear(pmd);
spin_unlock(&init_mm.page_table_lock);
-
- /*
- * For non-direct mapping, pages means
- * nothing.
- */
pages++;
+ } else {
+ /* If here, we are freeing vmemmap pages. */
+ memset((void *)addr, PAGE_INUSE, next - addr);
+
+ page_addr = page_address(pmd_page(*pmd));
+ if (!memchr_inv(page_addr, PAGE_INUSE,
+ PMD_SIZE)) {
+ free_pagetable(pmd_page(*pmd),
+ get_order(PMD_SIZE));
- continue;
+ spin_lock(&init_mm.page_table_lock);
+ pmd_clear(pmd);
+ spin_unlock(&init_mm.page_table_lock);
+ }
}
- /*
- * We use 2M page, but we need to remove part of them,
- * so split 2M page to 4K page.
- */
- pte_base = (pte_t *)alloc_low_page(&pte_phys);
- BUG_ON(!pte_base);
- __split_large_page((pte_t *)pmd, addr,
- (pte_t *)pte_base);
- split_pte = true;
-
- spin_lock(&init_mm.page_table_lock);
- pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
- spin_unlock(&init_mm.page_table_lock);
-
- flush_tlb_all();
+ continue;
}
pte_base = (pte_t *)map_low_page((pte_t *)pmd_page_vaddr(*pmd));
- remove_pte_table(pte_base, addr, next, direct, split_pte);
-
- if (!direct && split_pte) {
- page_addr = page_address(pmd_page(*pmd));
- if (!memchr_inv(page_addr, PAGE_INUSE, PMD_SIZE)) {
- free_pagetable(pmd_page(*pmd),
- get_order(PMD_SIZE));
- }
- }
-
+ remove_pte_table(pte_base, addr, next, direct);
free_pte_table(pte_base, pmd);
unmap_low_page(pte_base);
}
@@ -953,11 +908,10 @@ static void __meminit
remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
bool direct)
{
- unsigned long pmd_phys, next, pages = 0;
+ unsigned long next, pages = 0;
pmd_t *pmd_base;
pud_t *pud;
void *page_addr;
- bool split_pmd = false;
pud = pud_start + pud_index(addr);
for (; addr < end; addr = next, pud++) {
@@ -977,37 +931,27 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
pud_clear(pud);
spin_unlock(&init_mm.page_table_lock);
pages++;
- continue;
- }
+ } else {
+ /* If here, we are freeing vmemmap pages. */
+ memset((void *)addr, PAGE_INUSE, next - addr);
- /*
- * We use 1G page, but we need to remove part of them,
- * so split 1G page to 2M page.
- */
- pmd_base = (pmd_t *)alloc_low_page(&pmd_phys);
- BUG_ON(!pmd_base);
- __split_large_page((pte_t *)pud, addr,
- (pte_t *)pmd_base);
- split_pmd = true;
+ page_addr = page_address(pud_page(*pud));
+ if (!memchr_inv(page_addr, PAGE_INUSE,
+ PUD_SIZE)) {
+ free_pagetable(pud_page(*pud),
+ get_order(PUD_SIZE));
- spin_lock(&init_mm.page_table_lock);
- pud_populate(&init_mm, pud, __va(pmd_phys));
- spin_unlock(&init_mm.page_table_lock);
+ spin_lock(&init_mm.page_table_lock);
+ pud_clear(pud);
+ spin_unlock(&init_mm.page_table_lock);
+ }
+ }
- flush_tlb_all();
+ continue;
}
pmd_base = (pmd_t *)map_low_page((pmd_t *)pud_page_vaddr(*pud));
- remove_pmd_table(pmd_base, addr, next, direct, split_pmd);
-
- if (!direct && split_pmd) {
- page_addr = page_address(pud_page(*pud));
- if (!memchr_inv(page_addr, PAGE_INUSE, PUD_SIZE)) {
- free_pagetable(pud_page(*pud),
- get_order(PUD_SIZE));
- }
- }
-
+ remove_pmd_table(pmd_base, addr, next, direct);
free_pmd_table(pmd_base, pud);
unmap_low_page(pmd_base);
}
--
1.7.1
--
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>
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 3/5] Bug fix: Do not split pages when freeing pagetable pages.
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
The old way we free pagetable pages was wrong.
The old way is:
When we got a hugepage, we split it into smaller pages. And sometimes,
we only need to free some of the smaller pages because the others are
still in use. And the whole larger page will be freed if all the smaller
pages are not in use. All these were done in remove_pmd/pud_table().
But there is no way to know if the larger page has been split. As a result,
there is no way to decide when to split.
Actually, there is no need to split larger pages into smaller ones.
We do it in the following new way:
1) For direct mapped pages, all the pages were freed when they were offlined.
And since menmory offline is done section by section, all the memory ranges
being removed are aligned to PAGE_SIZE. So only need to deal with unaligned
pages when freeing vmemmap pages.
2) For vmemmap pages being used to store page_struct, if part of the larger
page is still in use, just fill the unused part with 0xFD. And when the
whole page is fulfilled with 0xFD, then free the larger page.
This problem is caused by the following related patch:
memory-hotplug-common-apis-to-support-page-tables-hot-remove.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix.patch
This patch will fix the problem based on the above patches.
Reported-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
arch/x86/mm/init_64.c | 148 +++++++++++++++---------------------------------
1 files changed, 46 insertions(+), 102 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 6d1a768..9fbed24 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -777,7 +777,7 @@ static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
static void __meminit
remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
- bool direct, bool split)
+ bool direct)
{
unsigned long next, pages = 0;
pte_t *pte;
@@ -807,23 +807,9 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
/*
* Do not free direct mapping pages since they were
* freed when offlining, or simplely not in use.
- *
- * Do not free pages split from larger page since only
- * the _count of the 1st page struct is available.
- * Free the larger page when it is fulfilled with 0xFD.
*/
- if (!direct) {
- if (split) {
- /*
- * Fill the split 4KB page with 0xFD.
- * When the whole 2MB page is fulfilled
- * with 0xFD, it could be freed.
- */
- memset((void *)addr, PAGE_INUSE,
- PAGE_SIZE);
- } else
- free_pagetable(pte_page(*pte), 0);
- }
+ if (!direct)
+ free_pagetable(pte_page(*pte), 0);
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
@@ -833,26 +819,24 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
pages++;
} else {
/*
+ * If we are here, we are freeing vmemmap pages since
+ * direct mapped memory ranges to be freed are aligned.
+ *
* If we are not removing the whole page, it means
- * other ptes in this page are being used and we cannot
- * remove them. So fill the unused ptes with 0xFD, and
- * remove the page when it is wholly filled with 0xFD.
+ * other page structs in this page are being used and
+ * we canot remove them. So fill the unused page_structs
+ * with 0xFD, and remove the page when it is wholly
+ * filled with 0xFD.
*/
memset((void *)addr, PAGE_INUSE, next - addr);
- /*
- * If the range is not aligned to PAGE_SIZE, then the
- * page is definitely not split from larger page.
- */
page_addr = page_address(pte_page(*pte));
if (!memchr_inv(page_addr, PAGE_INUSE, PAGE_SIZE)) {
- if (!direct)
- free_pagetable(pte_page(*pte), 0);
+ free_pagetable(pte_page(*pte), 0);
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
spin_unlock(&init_mm.page_table_lock);
- pages++;
}
}
}
@@ -865,13 +849,12 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
static void __meminit
remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
- bool direct, bool split)
+ bool direct)
{
- unsigned long pte_phys, next, pages = 0;
+ unsigned long next, pages = 0;
pte_t *pte_base;
pmd_t *pmd;
void *page_addr;
- bool split_pmd = split, split_pte = false;
pmd = pmd_start + pmd_index(addr);
for (; addr < end; addr = next, pmd++) {
@@ -883,63 +866,35 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
if (pmd_large(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
IS_ALIGNED(next, PMD_SIZE)) {
- if (!direct) {
- if (split_pmd) {
- /*
- * Fill the split 2MB page with
- * 0xFD. When the whole 1GB page
- * is fulfilled with 0xFD, it
- * could be freed.
- */
- memset((void *)addr, PAGE_INUSE,
- PMD_SIZE);
- } else {
- free_pagetable(pmd_page(*pmd),
+ if (!direct)
+ free_pagetable(pmd_page(*pmd),
get_order(PMD_SIZE));
- }
- }
spin_lock(&init_mm.page_table_lock);
pmd_clear(pmd);
spin_unlock(&init_mm.page_table_lock);
-
- /*
- * For non-direct mapping, pages means
- * nothing.
- */
pages++;
+ } else {
+ /* If here, we are freeing vmemmap pages. */
+ memset((void *)addr, PAGE_INUSE, next - addr);
+
+ page_addr = page_address(pmd_page(*pmd));
+ if (!memchr_inv(page_addr, PAGE_INUSE,
+ PMD_SIZE)) {
+ free_pagetable(pmd_page(*pmd),
+ get_order(PMD_SIZE));
- continue;
+ spin_lock(&init_mm.page_table_lock);
+ pmd_clear(pmd);
+ spin_unlock(&init_mm.page_table_lock);
+ }
}
- /*
- * We use 2M page, but we need to remove part of them,
- * so split 2M page to 4K page.
- */
- pte_base = (pte_t *)alloc_low_page(&pte_phys);
- BUG_ON(!pte_base);
- __split_large_page((pte_t *)pmd, addr,
- (pte_t *)pte_base);
- split_pte = true;
-
- spin_lock(&init_mm.page_table_lock);
- pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
- spin_unlock(&init_mm.page_table_lock);
-
- flush_tlb_all();
+ continue;
}
pte_base = (pte_t *)map_low_page((pte_t *)pmd_page_vaddr(*pmd));
- remove_pte_table(pte_base, addr, next, direct, split_pte);
-
- if (!direct && split_pte) {
- page_addr = page_address(pmd_page(*pmd));
- if (!memchr_inv(page_addr, PAGE_INUSE, PMD_SIZE)) {
- free_pagetable(pmd_page(*pmd),
- get_order(PMD_SIZE));
- }
- }
-
+ remove_pte_table(pte_base, addr, next, direct);
free_pte_table(pte_base, pmd);
unmap_low_page(pte_base);
}
@@ -953,11 +908,10 @@ static void __meminit
remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
bool direct)
{
- unsigned long pmd_phys, next, pages = 0;
+ unsigned long next, pages = 0;
pmd_t *pmd_base;
pud_t *pud;
void *page_addr;
- bool split_pmd = false;
pud = pud_start + pud_index(addr);
for (; addr < end; addr = next, pud++) {
@@ -977,37 +931,27 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
pud_clear(pud);
spin_unlock(&init_mm.page_table_lock);
pages++;
- continue;
- }
+ } else {
+ /* If here, we are freeing vmemmap pages. */
+ memset((void *)addr, PAGE_INUSE, next - addr);
- /*
- * We use 1G page, but we need to remove part of them,
- * so split 1G page to 2M page.
- */
- pmd_base = (pmd_t *)alloc_low_page(&pmd_phys);
- BUG_ON(!pmd_base);
- __split_large_page((pte_t *)pud, addr,
- (pte_t *)pmd_base);
- split_pmd = true;
+ page_addr = page_address(pud_page(*pud));
+ if (!memchr_inv(page_addr, PAGE_INUSE,
+ PUD_SIZE)) {
+ free_pagetable(pud_page(*pud),
+ get_order(PUD_SIZE));
- spin_lock(&init_mm.page_table_lock);
- pud_populate(&init_mm, pud, __va(pmd_phys));
- spin_unlock(&init_mm.page_table_lock);
+ spin_lock(&init_mm.page_table_lock);
+ pud_clear(pud);
+ spin_unlock(&init_mm.page_table_lock);
+ }
+ }
- flush_tlb_all();
+ continue;
}
pmd_base = (pmd_t *)map_low_page((pmd_t *)pud_page_vaddr(*pud));
- remove_pmd_table(pmd_base, addr, next, direct, split_pmd);
-
- if (!direct && split_pmd) {
- page_addr = page_address(pud_page(*pud));
- if (!memchr_inv(page_addr, PAGE_INUSE, PUD_SIZE)) {
- free_pagetable(pud_page(*pud),
- get_order(PUD_SIZE));
- }
- }
-
+ remove_pmd_table(pmd_base, addr, next, direct);
free_pmd_table(pmd_base, pud);
unmap_low_page(pmd_base);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 3/5] Bug fix: Do not split pages when freeing pagetable pages.
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: linux-mm, x86, linuxppc-dev, linux-kernel, linux-acpi
The old way we free pagetable pages was wrong.
The old way is:
When we got a hugepage, we split it into smaller pages. And sometimes,
we only need to free some of the smaller pages because the others are
still in use. And the whole larger page will be freed if all the smaller
pages are not in use. All these were done in remove_pmd/pud_table().
But there is no way to know if the larger page has been split. As a result,
there is no way to decide when to split.
Actually, there is no need to split larger pages into smaller ones.
We do it in the following new way:
1) For direct mapped pages, all the pages were freed when they were offlined.
And since menmory offline is done section by section, all the memory ranges
being removed are aligned to PAGE_SIZE. So only need to deal with unaligned
pages when freeing vmemmap pages.
2) For vmemmap pages being used to store page_struct, if part of the larger
page is still in use, just fill the unused part with 0xFD. And when the
whole page is fulfilled with 0xFD, then free the larger page.
This problem is caused by the following related patch:
memory-hotplug-common-apis-to-support-page-tables-hot-remove.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix.patch
memory-hotplug-common-apis-to-support-page-tables-hot-remove-fix-fix-fix-fix.patch
This patch will fix the problem based on the above patches.
Reported-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
arch/x86/mm/init_64.c | 148 +++++++++++++++---------------------------------
1 files changed, 46 insertions(+), 102 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 6d1a768..9fbed24 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -777,7 +777,7 @@ static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
static void __meminit
remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
- bool direct, bool split)
+ bool direct)
{
unsigned long next, pages = 0;
pte_t *pte;
@@ -807,23 +807,9 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
/*
* Do not free direct mapping pages since they were
* freed when offlining, or simplely not in use.
- *
- * Do not free pages split from larger page since only
- * the _count of the 1st page struct is available.
- * Free the larger page when it is fulfilled with 0xFD.
*/
- if (!direct) {
- if (split) {
- /*
- * Fill the split 4KB page with 0xFD.
- * When the whole 2MB page is fulfilled
- * with 0xFD, it could be freed.
- */
- memset((void *)addr, PAGE_INUSE,
- PAGE_SIZE);
- } else
- free_pagetable(pte_page(*pte), 0);
- }
+ if (!direct)
+ free_pagetable(pte_page(*pte), 0);
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
@@ -833,26 +819,24 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
pages++;
} else {
/*
+ * If we are here, we are freeing vmemmap pages since
+ * direct mapped memory ranges to be freed are aligned.
+ *
* If we are not removing the whole page, it means
- * other ptes in this page are being used and we cannot
- * remove them. So fill the unused ptes with 0xFD, and
- * remove the page when it is wholly filled with 0xFD.
+ * other page structs in this page are being used and
+ * we canot remove them. So fill the unused page_structs
+ * with 0xFD, and remove the page when it is wholly
+ * filled with 0xFD.
*/
memset((void *)addr, PAGE_INUSE, next - addr);
- /*
- * If the range is not aligned to PAGE_SIZE, then the
- * page is definitely not split from larger page.
- */
page_addr = page_address(pte_page(*pte));
if (!memchr_inv(page_addr, PAGE_INUSE, PAGE_SIZE)) {
- if (!direct)
- free_pagetable(pte_page(*pte), 0);
+ free_pagetable(pte_page(*pte), 0);
spin_lock(&init_mm.page_table_lock);
pte_clear(&init_mm, addr, pte);
spin_unlock(&init_mm.page_table_lock);
- pages++;
}
}
}
@@ -865,13 +849,12 @@ remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
static void __meminit
remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
- bool direct, bool split)
+ bool direct)
{
- unsigned long pte_phys, next, pages = 0;
+ unsigned long next, pages = 0;
pte_t *pte_base;
pmd_t *pmd;
void *page_addr;
- bool split_pmd = split, split_pte = false;
pmd = pmd_start + pmd_index(addr);
for (; addr < end; addr = next, pmd++) {
@@ -883,63 +866,35 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
if (pmd_large(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
IS_ALIGNED(next, PMD_SIZE)) {
- if (!direct) {
- if (split_pmd) {
- /*
- * Fill the split 2MB page with
- * 0xFD. When the whole 1GB page
- * is fulfilled with 0xFD, it
- * could be freed.
- */
- memset((void *)addr, PAGE_INUSE,
- PMD_SIZE);
- } else {
- free_pagetable(pmd_page(*pmd),
+ if (!direct)
+ free_pagetable(pmd_page(*pmd),
get_order(PMD_SIZE));
- }
- }
spin_lock(&init_mm.page_table_lock);
pmd_clear(pmd);
spin_unlock(&init_mm.page_table_lock);
-
- /*
- * For non-direct mapping, pages means
- * nothing.
- */
pages++;
+ } else {
+ /* If here, we are freeing vmemmap pages. */
+ memset((void *)addr, PAGE_INUSE, next - addr);
+
+ page_addr = page_address(pmd_page(*pmd));
+ if (!memchr_inv(page_addr, PAGE_INUSE,
+ PMD_SIZE)) {
+ free_pagetable(pmd_page(*pmd),
+ get_order(PMD_SIZE));
- continue;
+ spin_lock(&init_mm.page_table_lock);
+ pmd_clear(pmd);
+ spin_unlock(&init_mm.page_table_lock);
+ }
}
- /*
- * We use 2M page, but we need to remove part of them,
- * so split 2M page to 4K page.
- */
- pte_base = (pte_t *)alloc_low_page(&pte_phys);
- BUG_ON(!pte_base);
- __split_large_page((pte_t *)pmd, addr,
- (pte_t *)pte_base);
- split_pte = true;
-
- spin_lock(&init_mm.page_table_lock);
- pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
- spin_unlock(&init_mm.page_table_lock);
-
- flush_tlb_all();
+ continue;
}
pte_base = (pte_t *)map_low_page((pte_t *)pmd_page_vaddr(*pmd));
- remove_pte_table(pte_base, addr, next, direct, split_pte);
-
- if (!direct && split_pte) {
- page_addr = page_address(pmd_page(*pmd));
- if (!memchr_inv(page_addr, PAGE_INUSE, PMD_SIZE)) {
- free_pagetable(pmd_page(*pmd),
- get_order(PMD_SIZE));
- }
- }
-
+ remove_pte_table(pte_base, addr, next, direct);
free_pte_table(pte_base, pmd);
unmap_low_page(pte_base);
}
@@ -953,11 +908,10 @@ static void __meminit
remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
bool direct)
{
- unsigned long pmd_phys, next, pages = 0;
+ unsigned long next, pages = 0;
pmd_t *pmd_base;
pud_t *pud;
void *page_addr;
- bool split_pmd = false;
pud = pud_start + pud_index(addr);
for (; addr < end; addr = next, pud++) {
@@ -977,37 +931,27 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
pud_clear(pud);
spin_unlock(&init_mm.page_table_lock);
pages++;
- continue;
- }
+ } else {
+ /* If here, we are freeing vmemmap pages. */
+ memset((void *)addr, PAGE_INUSE, next - addr);
- /*
- * We use 1G page, but we need to remove part of them,
- * so split 1G page to 2M page.
- */
- pmd_base = (pmd_t *)alloc_low_page(&pmd_phys);
- BUG_ON(!pmd_base);
- __split_large_page((pte_t *)pud, addr,
- (pte_t *)pmd_base);
- split_pmd = true;
+ page_addr = page_address(pud_page(*pud));
+ if (!memchr_inv(page_addr, PAGE_INUSE,
+ PUD_SIZE)) {
+ free_pagetable(pud_page(*pud),
+ get_order(PUD_SIZE));
- spin_lock(&init_mm.page_table_lock);
- pud_populate(&init_mm, pud, __va(pmd_phys));
- spin_unlock(&init_mm.page_table_lock);
+ spin_lock(&init_mm.page_table_lock);
+ pud_clear(pud);
+ spin_unlock(&init_mm.page_table_lock);
+ }
+ }
- flush_tlb_all();
+ continue;
}
pmd_base = (pmd_t *)map_low_page((pmd_t *)pud_page_vaddr(*pud));
- remove_pmd_table(pmd_base, addr, next, direct, split_pmd);
-
- if (!direct && split_pmd) {
- page_addr = page_address(pud_page(*pud));
- if (!memchr_inv(page_addr, PAGE_INUSE, PUD_SIZE)) {
- free_pagetable(pud_page(*pud),
- get_order(PUD_SIZE));
- }
- }
-
+ remove_pmd_table(pmd_base, addr, next, direct);
free_pmd_table(pmd_base, pud);
unmap_low_page(pmd_base);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH Bug fix 4/5] Bug fix: Fix section mismatch problem of release_firmware_map_entry().
2013-01-22 11:42 ` Tang Chen
(?)
@ 2013-01-22 11:43 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
The function release_firmware_map_entry() references the function
__meminit firmware_map_find_entry_in_list(). So it should also have
__meminit.
And since the firmware_map_entry->kobj is initialized with memmap_ktype,
the memmap_ktype should also be prefixed by __refdata.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 0710179..658fdd4 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -103,7 +103,7 @@ to_memmap_entry(struct kobject *kobj)
return container_of(kobj, struct firmware_map_entry, kobj);
}
-static void release_firmware_map_entry(struct kobject *kobj)
+static void __meminit release_firmware_map_entry(struct kobject *kobj)
{
struct firmware_map_entry *entry = to_memmap_entry(kobj);
@@ -127,7 +127,7 @@ static void release_firmware_map_entry(struct kobject *kobj)
kfree(entry);
}
-static struct kobj_type memmap_ktype = {
+static struct kobj_type __refdata memmap_ktype = {
.release = release_firmware_map_entry,
.sysfs_ops = &memmap_attr_ops,
.default_attrs = def_attrs,
--
1.7.1
--
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>
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 4/5] Bug fix: Fix section mismatch problem of release_firmware_map_entry().
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
The function release_firmware_map_entry() references the function
__meminit firmware_map_find_entry_in_list(). So it should also have
__meminit.
And since the firmware_map_entry->kobj is initialized with memmap_ktype,
the memmap_ktype should also be prefixed by __refdata.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 0710179..658fdd4 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -103,7 +103,7 @@ to_memmap_entry(struct kobject *kobj)
return container_of(kobj, struct firmware_map_entry, kobj);
}
-static void release_firmware_map_entry(struct kobject *kobj)
+static void __meminit release_firmware_map_entry(struct kobject *kobj)
{
struct firmware_map_entry *entry = to_memmap_entry(kobj);
@@ -127,7 +127,7 @@ static void release_firmware_map_entry(struct kobject *kobj)
kfree(entry);
}
-static struct kobj_type memmap_ktype = {
+static struct kobj_type __refdata memmap_ktype = {
.release = release_firmware_map_entry,
.sysfs_ops = &memmap_attr_ops,
.default_attrs = def_attrs,
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH Bug fix 4/5] Bug fix: Fix section mismatch problem of release_firmware_map_entry().
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: linux-mm, x86, linuxppc-dev, linux-kernel, linux-acpi
The function release_firmware_map_entry() references the function
__meminit firmware_map_find_entry_in_list(). So it should also have
__meminit.
And since the firmware_map_entry->kobj is initialized with memmap_ktype,
the memmap_ktype should also be prefixed by __refdata.
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 0710179..658fdd4 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -103,7 +103,7 @@ to_memmap_entry(struct kobject *kobj)
return container_of(kobj, struct firmware_map_entry, kobj);
}
-static void release_firmware_map_entry(struct kobject *kobj)
+static void __meminit release_firmware_map_entry(struct kobject *kobj)
{
struct firmware_map_entry *entry = to_memmap_entry(kobj);
@@ -127,7 +127,7 @@ static void release_firmware_map_entry(struct kobject *kobj)
kfree(entry);
}
-static struct kobj_type memmap_ktype = {
+static struct kobj_type __refdata memmap_ktype = {
.release = release_firmware_map_entry,
.sysfs_ops = &memmap_attr_ops,
.default_attrs = def_attrs,
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH Bug fix 5/5] Bug fix: Fix the doc format in drivers/firmware/memmap.c
2013-01-22 11:42 ` Tang Chen
(?)
@ 2013-01-22 11:43 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
Make the comments in drivers/firmware/memmap.c kernel-doc compliant.
Reported-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 658fdd4..0b5b5f6 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -209,7 +209,7 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
}
/*
- * firmware_map_find_entry_in_list: Search memmap entry in a given list.
+ * firmware_map_find_entry_in_list() - Search memmap entry in a given list.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -219,7 +219,7 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
* given list. The caller must hold map_entries_lock, and must not release
* the lock until the processing of the returned entry has completed.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
@@ -237,7 +237,7 @@ firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
}
/*
- * firmware_map_find_entry: Search memmap entry in map_entries.
+ * firmware_map_find_entry() - Search memmap entry in map_entries.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -246,7 +246,7 @@ firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
* The caller must hold map_entries_lock, and must not release the lock
* until the processing of the returned entry has completed.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry(u64 start, u64 end, const char *type)
@@ -255,7 +255,7 @@ firmware_map_find_entry(u64 start, u64 end, const char *type)
}
/*
- * firmware_map_find_entry_bootmem: Search memmap entry in map_entries_bootmem.
+ * firmware_map_find_entry_bootmem() - Search memmap entry in map_entries_bootmem.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -263,7 +263,7 @@ firmware_map_find_entry(u64 start, u64 end, const char *type)
* This function is similar to firmware_map_find_entry except that it find the
* given entry in map_entries_bootmem.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry_bootmem(u64 start, u64 end, const char *type)
--
1.7.1
--
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>
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH Bug fix 5/5] Bug fix: Fix the doc format in drivers/firmware/memmap.c
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
Make the comments in drivers/firmware/memmap.c kernel-doc compliant.
Reported-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 658fdd4..0b5b5f6 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -209,7 +209,7 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
}
/*
- * firmware_map_find_entry_in_list: Search memmap entry in a given list.
+ * firmware_map_find_entry_in_list() - Search memmap entry in a given list.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -219,7 +219,7 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
* given list. The caller must hold map_entries_lock, and must not release
* the lock until the processing of the returned entry has completed.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
@@ -237,7 +237,7 @@ firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
}
/*
- * firmware_map_find_entry: Search memmap entry in map_entries.
+ * firmware_map_find_entry() - Search memmap entry in map_entries.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -246,7 +246,7 @@ firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
* The caller must hold map_entries_lock, and must not release the lock
* until the processing of the returned entry has completed.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry(u64 start, u64 end, const char *type)
@@ -255,7 +255,7 @@ firmware_map_find_entry(u64 start, u64 end, const char *type)
}
/*
- * firmware_map_find_entry_bootmem: Search memmap entry in map_entries_bootmem.
+ * firmware_map_find_entry_bootmem() - Search memmap entry in map_entries_bootmem.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -263,7 +263,7 @@ firmware_map_find_entry(u64 start, u64 end, const char *type)
* This function is similar to firmware_map_find_entry except that it find the
* given entry in map_entries_bootmem.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry_bootmem(u64 start, u64 end, const char *type)
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH Bug fix 5/5] Bug fix: Fix the doc format in drivers/firmware/memmap.c
@ 2013-01-22 11:43 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-22 11:43 UTC (permalink / raw)
To: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr
Cc: linux-mm, x86, linuxppc-dev, linux-kernel, linux-acpi
Make the comments in drivers/firmware/memmap.c kernel-doc compliant.
Reported-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
drivers/firmware/memmap.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 658fdd4..0b5b5f6 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -209,7 +209,7 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
}
/*
- * firmware_map_find_entry_in_list: Search memmap entry in a given list.
+ * firmware_map_find_entry_in_list() - Search memmap entry in a given list.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -219,7 +219,7 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
* given list. The caller must hold map_entries_lock, and must not release
* the lock until the processing of the returned entry has completed.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
@@ -237,7 +237,7 @@ firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
}
/*
- * firmware_map_find_entry: Search memmap entry in map_entries.
+ * firmware_map_find_entry() - Search memmap entry in map_entries.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -246,7 +246,7 @@ firmware_map_find_entry_in_list(u64 start, u64 end, const char *type,
* The caller must hold map_entries_lock, and must not release the lock
* until the processing of the returned entry has completed.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry(u64 start, u64 end, const char *type)
@@ -255,7 +255,7 @@ firmware_map_find_entry(u64 start, u64 end, const char *type)
}
/*
- * firmware_map_find_entry_bootmem: Search memmap entry in map_entries_bootmem.
+ * firmware_map_find_entry_bootmem() - Search memmap entry in map_entries_bootmem.
* @start: Start of the memory range.
* @end: End of the memory range (exclusive).
* @type: Type of the memory range.
@@ -263,7 +263,7 @@ firmware_map_find_entry(u64 start, u64 end, const char *type)
* This function is similar to firmware_map_find_entry except that it find the
* given entry in map_entries_bootmem.
*
- * Return pointer to the entry to be found on success, or NULL on failure.
+ * Return: Pointer to the entry to be found on success, or NULL on failure.
*/
static struct firmware_map_entry * __meminit
firmware_map_find_entry_bootmem(u64 start, u64 end, const char *type)
--
1.7.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-22 11:42 ` Tang Chen
(?)
@ 2013-01-23 12:29 ` Simon Jeons
-1 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-23 12:29 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> Here are some bug fix patches for physical memory hot-remove. All these
> patches are based on the latest -mm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> And patch1 and patch3 are very important.
> patch1: free compound pages when freeing memmap, otherwise the kernel
> will panic the next time memory is hot-added.
> patch3: the old way of freeing pagetable pages was wrong. We should never
> split larger pages into small ones.
>
>
Hi Tang,
I remember your big physical memory hot-remove patchset has already
merged by Andrew, but where I can find it? Could you give me git tree
address?
> Lai Jiangshan (1):
> Bug-fix: mempolicy: fix is_valid_nodemask()
>
> Tang Chen (3):
> Bug fix: Do not split pages when freeing pagetable pages.
> Bug fix: Fix section mismatch problem of
> release_firmware_map_entry().
> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>
> Wen Congyang (1):
> Bug fix: consider compound pages when free memmap
>
> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
> drivers/firmware/memmap.c | 16 +++---
> mm/mempolicy.c | 36 +++++++----
> mm/sparse.c | 2 +-
> 4 files changed, 77 insertions(+), 125 deletions(-)
>
> --
> 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>
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-23 12:29 ` Simon Jeons
0 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-23 12:29 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> Here are some bug fix patches for physical memory hot-remove. All these
> patches are based on the latest -mm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> And patch1 and patch3 are very important.
> patch1: free compound pages when freeing memmap, otherwise the kernel
> will panic the next time memory is hot-added.
> patch3: the old way of freeing pagetable pages was wrong. We should never
> split larger pages into small ones.
>
>
Hi Tang,
I remember your big physical memory hot-remove patchset has already
merged by Andrew, but where I can find it? Could you give me git tree
address?
> Lai Jiangshan (1):
> Bug-fix: mempolicy: fix is_valid_nodemask()
>
> Tang Chen (3):
> Bug fix: Do not split pages when freeing pagetable pages.
> Bug fix: Fix section mismatch problem of
> release_firmware_map_entry().
> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>
> Wen Congyang (1):
> Bug fix: consider compound pages when free memmap
>
> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
> drivers/firmware/memmap.c | 16 +++---
> mm/mempolicy.c | 36 +++++++----
> mm/sparse.c | 2 +-
> 4 files changed, 77 insertions(+), 125 deletions(-)
>
> --
> 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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-23 12:29 ` Simon Jeons
0 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-23 12:29 UTC (permalink / raw)
To: Tang Chen
Cc: linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, jiang.liu,
wency, julian.calaby, glommer, wujianguo, yinghai, laijs,
linux-kernel, minchan.kim, akpm, linuxppc-dev
On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> Here are some bug fix patches for physical memory hot-remove. All these
> patches are based on the latest -mm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> And patch1 and patch3 are very important.
> patch1: free compound pages when freeing memmap, otherwise the kernel
> will panic the next time memory is hot-added.
> patch3: the old way of freeing pagetable pages was wrong. We should never
> split larger pages into small ones.
>
>
Hi Tang,
I remember your big physical memory hot-remove patchset has already
merged by Andrew, but where I can find it? Could you give me git tree
address?
> Lai Jiangshan (1):
> Bug-fix: mempolicy: fix is_valid_nodemask()
>
> Tang Chen (3):
> Bug fix: Do not split pages when freeing pagetable pages.
> Bug fix: Fix section mismatch problem of
> release_firmware_map_entry().
> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>
> Wen Congyang (1):
> Bug fix: consider compound pages when free memmap
>
> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
> drivers/firmware/memmap.c | 16 +++---
> mm/mempolicy.c | 36 +++++++----
> mm/sparse.c | 2 +-
> 4 files changed, 77 insertions(+), 125 deletions(-)
>
> --
> 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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-23 12:29 ` Simon Jeons
(?)
@ 2013-01-23 13:17 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-23 13:17 UTC (permalink / raw)
To: Simon Jeons
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On 01/23/2013 08:29 PM, Simon Jeons wrote:
> Hi Tang,
>
> I remember your big physical memory hot-remove patchset has already
> merged by Andrew, but where I can find it? Could you give me git tree
> address?
Hi Simon,
You can find all the physical memory hot-remove patches and related bugfix
patches from the following url:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
Thanks. :)
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-23 13:17 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-23 13:17 UTC (permalink / raw)
To: Simon Jeons
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On 01/23/2013 08:29 PM, Simon Jeons wrote:
> Hi Tang,
>
> I remember your big physical memory hot-remove patchset has already
> merged by Andrew, but where I can find it? Could you give me git tree
> address?
Hi Simon,
You can find all the physical memory hot-remove patches and related bugfix
patches from the following url:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
Thanks. :)
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-23 13:17 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-23 13:17 UTC (permalink / raw)
To: Simon Jeons
Cc: linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, jiang.liu,
wency, julian.calaby, glommer, wujianguo, yinghai, laijs,
linux-kernel, minchan.kim, akpm, linuxppc-dev
On 01/23/2013 08:29 PM, Simon Jeons wrote:
> Hi Tang,
>
> I remember your big physical memory hot-remove patchset has already
> merged by Andrew, but where I can find it? Could you give me git tree
> address?
Hi Simon,
You can find all the physical memory hot-remove patches and related bugfix
patches from the following url:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
Thanks. :)
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-23 13:17 ` Tang Chen
(?)
@ 2013-01-24 0:35 ` Simon Jeons
-1 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-24 0:35 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> > Hi Tang,
> >
> > I remember your big physical memory hot-remove patchset has already
> > merged by Andrew, but where I can find it? Could you give me git tree
> > address?
>
> Hi Simon,
>
> You can find all the physical memory hot-remove patches and related bugfix
> patches from the following url:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
~/linux-next$ git remote -v
origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(fetch)
origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(push)
~/linux-next$ git branch
* akpm
master
~/linux-next$ wc -l mm/memory_hotplug.c
1173 mm/memory_hotplug.c
I still can't find it. :(
>
>
> Thanks. :)
>
> --
> 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>
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-24 0:35 ` Simon Jeons
0 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-24 0:35 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> > Hi Tang,
> >
> > I remember your big physical memory hot-remove patchset has already
> > merged by Andrew, but where I can find it? Could you give me git tree
> > address?
>
> Hi Simon,
>
> You can find all the physical memory hot-remove patches and related bugfix
> patches from the following url:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
~/linux-next$ git remote -v
origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(fetch)
origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(push)
~/linux-next$ git branch
* akpm
master
~/linux-next$ wc -l mm/memory_hotplug.c
1173 mm/memory_hotplug.c
I still can't find it. :(
>
>
> Thanks. :)
>
> --
> 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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-24 0:35 ` Simon Jeons
0 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-24 0:35 UTC (permalink / raw)
To: Tang Chen
Cc: linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, jiang.liu,
wency, julian.calaby, glommer, wujianguo, yinghai, laijs,
linux-kernel, minchan.kim, akpm, linuxppc-dev
On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> > Hi Tang,
> >
> > I remember your big physical memory hot-remove patchset has already
> > merged by Andrew, but where I can find it? Could you give me git tree
> > address?
>
> Hi Simon,
>
> You can find all the physical memory hot-remove patches and related bugfix
> patches from the following url:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
~/linux-next$ git remote -v
origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(fetch)
origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(push)
~/linux-next$ git branch
* akpm
master
~/linux-next$ wc -l mm/memory_hotplug.c
1173 mm/memory_hotplug.c
I still can't find it. :(
>
>
> Thanks. :)
>
> --
> 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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-24 0:35 ` Simon Jeons
(?)
@ 2013-01-24 1:36 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-24 1:36 UTC (permalink / raw)
To: Simon Jeons
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On 01/24/2013 08:35 AM, Simon Jeons wrote:
> On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
>> On 01/23/2013 08:29 PM, Simon Jeons wrote:
>>> Hi Tang,
>>>
>>> I remember your big physical memory hot-remove patchset has already
>>> merged by Andrew, but where I can find it? Could you give me git tree
>>> address?
>>
>> Hi Simon,
>>
>> You can find all the physical memory hot-remove patches and related bugfix
>> patches from the following url:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> ~/linux-next$ git remote -v
> origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (fetch)
> origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (push)
> ~/linux-next$ git branch
> * akpm
> master
> ~/linux-next$ wc -l mm/memory_hotplug.c
> 1173 mm/memory_hotplug.c
>
> I still can't find it. :(
Hi Simon,
It's weird, in my akpm git log, I can find the following commit.
commit deed0460e01b3968f2cf46fb94851936535b7e0d
Author: Tang Chen <tangchen@cn.fujitsu.com>
Date: Sat Jan 19 11:07:13 2013 +1100
memory-hotplug: do not allocate pgdat if it was not freed when offline.
And there are 15 related patches following it. And above it, there are
some more related bugfix
from me and Andrew. They are all in -mm tree.
This is what I did:
$ git remote add next
http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git remote update next
$ git checkout -b next-akpm remotes/next/akpm
Please pull your tree and try again. :)
Thanks. :)
>
>>
>>
>> Thanks. :)
>>
>> --
>> 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>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-24 1:36 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-24 1:36 UTC (permalink / raw)
To: Simon Jeons
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On 01/24/2013 08:35 AM, Simon Jeons wrote:
> On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
>> On 01/23/2013 08:29 PM, Simon Jeons wrote:
>>> Hi Tang,
>>>
>>> I remember your big physical memory hot-remove patchset has already
>>> merged by Andrew, but where I can find it? Could you give me git tree
>>> address?
>>
>> Hi Simon,
>>
>> You can find all the physical memory hot-remove patches and related bugfix
>> patches from the following url:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> ~/linux-next$ git remote -v
> origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (fetch)
> origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (push)
> ~/linux-next$ git branch
> * akpm
> master
> ~/linux-next$ wc -l mm/memory_hotplug.c
> 1173 mm/memory_hotplug.c
>
> I still can't find it. :(
Hi Simon,
It's weird, in my akpm git log, I can find the following commit.
commit deed0460e01b3968f2cf46fb94851936535b7e0d
Author: Tang Chen <tangchen@cn.fujitsu.com>
Date: Sat Jan 19 11:07:13 2013 +1100
memory-hotplug: do not allocate pgdat if it was not freed when offline.
And there are 15 related patches following it. And above it, there are
some more related bugfix
from me and Andrew. They are all in -mm tree.
This is what I did:
$ git remote add next
http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git remote update next
$ git checkout -b next-akpm remotes/next/akpm
Please pull your tree and try again. :)
Thanks. :)
>
>>
>>
>> Thanks. :)
>>
>> --
>> 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>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-24 1:36 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-24 1:36 UTC (permalink / raw)
To: Simon Jeons
Cc: linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, jiang.liu,
wency, julian.calaby, glommer, wujianguo, yinghai, laijs,
linux-kernel, minchan.kim, akpm, linuxppc-dev
On 01/24/2013 08:35 AM, Simon Jeons wrote:
> On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
>> On 01/23/2013 08:29 PM, Simon Jeons wrote:
>>> Hi Tang,
>>>
>>> I remember your big physical memory hot-remove patchset has already
>>> merged by Andrew, but where I can find it? Could you give me git tree
>>> address?
>>
>> Hi Simon,
>>
>> You can find all the physical memory hot-remove patches and related bugfix
>> patches from the following url:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> ~/linux-next$ git remote -v
> origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (fetch)
> origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (push)
> ~/linux-next$ git branch
> * akpm
> master
> ~/linux-next$ wc -l mm/memory_hotplug.c
> 1173 mm/memory_hotplug.c
>
> I still can't find it. :(
Hi Simon,
It's weird, in my akpm git log, I can find the following commit.
commit deed0460e01b3968f2cf46fb94851936535b7e0d
Author: Tang Chen <tangchen@cn.fujitsu.com>
Date: Sat Jan 19 11:07:13 2013 +1100
memory-hotplug: do not allocate pgdat if it was not freed when offline.
And there are 15 related patches following it. And above it, there are
some more related bugfix
from me and Andrew. They are all in -mm tree.
This is what I did:
$ git remote add next
http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git remote update next
$ git checkout -b next-akpm remotes/next/akpm
Please pull your tree and try again. :)
Thanks. :)
>
>>
>>
>> Thanks. :)
>>
>> --
>> 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>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-24 1:36 ` Tang Chen
(?)
@ 2013-01-24 1:48 ` Simon Jeons
-1 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-24 1:48 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Thu, 2013-01-24 at 09:36 +0800, Tang Chen wrote:
> On 01/24/2013 08:35 AM, Simon Jeons wrote:
> > On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> >> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> >>> Hi Tang,
> >>>
> >>> I remember your big physical memory hot-remove patchset has already
> >>> merged by Andrew, but where I can find it? Could you give me git tree
> >>> address?
> >>
> >> Hi Simon,
> >>
> >> You can find all the physical memory hot-remove patches and related bugfix
> >> patches from the following url:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >
> > ~/linux-next$ git remote -v
> > origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > (fetch)
> > origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > (push)
> > ~/linux-next$ git branch
> > * akpm
> > master
> > ~/linux-next$ wc -l mm/memory_hotplug.c
> > 1173 mm/memory_hotplug.c
> >
> > I still can't find it. :(
>
> Hi Simon,
>
> It's weird, in my akpm git log, I can find the following commit.
>
> commit deed0460e01b3968f2cf46fb94851936535b7e0d
> Author: Tang Chen <tangchen@cn.fujitsu.com>
> Date: Sat Jan 19 11:07:13 2013 +1100
>
> memory-hotplug: do not allocate pgdat if it was not freed when offline.
>
> And there are 15 related patches following it. And above it, there are
> some more related bugfix
> from me and Andrew. They are all in -mm tree.
>
> This is what I did:
>
> $ git remote add next
> http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> $ git remote update next
> $ git checkout -b next-akpm remotes/next/akpm
>
> Please pull your tree and try again. :)
Got it. Thanks! :)
>
> Thanks. :)
>
>
> >
> >>
> >>
> >> Thanks. :)
> >>
> >> --
> >> 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>
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-24 1:48 ` Simon Jeons
0 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-24 1:48 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Thu, 2013-01-24 at 09:36 +0800, Tang Chen wrote:
> On 01/24/2013 08:35 AM, Simon Jeons wrote:
> > On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> >> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> >>> Hi Tang,
> >>>
> >>> I remember your big physical memory hot-remove patchset has already
> >>> merged by Andrew, but where I can find it? Could you give me git tree
> >>> address?
> >>
> >> Hi Simon,
> >>
> >> You can find all the physical memory hot-remove patches and related bugfix
> >> patches from the following url:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >
> > ~/linux-next$ git remote -v
> > origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > (fetch)
> > origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > (push)
> > ~/linux-next$ git branch
> > * akpm
> > master
> > ~/linux-next$ wc -l mm/memory_hotplug.c
> > 1173 mm/memory_hotplug.c
> >
> > I still can't find it. :(
>
> Hi Simon,
>
> It's weird, in my akpm git log, I can find the following commit.
>
> commit deed0460e01b3968f2cf46fb94851936535b7e0d
> Author: Tang Chen <tangchen@cn.fujitsu.com>
> Date: Sat Jan 19 11:07:13 2013 +1100
>
> memory-hotplug: do not allocate pgdat if it was not freed when offline.
>
> And there are 15 related patches following it. And above it, there are
> some more related bugfix
> from me and Andrew. They are all in -mm tree.
>
> This is what I did:
>
> $ git remote add next
> http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> $ git remote update next
> $ git checkout -b next-akpm remotes/next/akpm
>
> Please pull your tree and try again. :)
Got it. Thanks! :)
>
> Thanks. :)
>
>
> >
> >>
> >>
> >> Thanks. :)
> >>
> >> --
> >> 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>
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-24 1:48 ` Simon Jeons
0 siblings, 0 replies; 48+ messages in thread
From: Simon Jeons @ 2013-01-24 1:48 UTC (permalink / raw)
To: Tang Chen
Cc: linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, jiang.liu,
wency, julian.calaby, glommer, wujianguo, yinghai, laijs,
linux-kernel, minchan.kim, akpm, linuxppc-dev
On Thu, 2013-01-24 at 09:36 +0800, Tang Chen wrote:
> On 01/24/2013 08:35 AM, Simon Jeons wrote:
> > On Wed, 2013-01-23 at 21:17 +0800, Tang Chen wrote:
> >> On 01/23/2013 08:29 PM, Simon Jeons wrote:
> >>> Hi Tang,
> >>>
> >>> I remember your big physical memory hot-remove patchset has already
> >>> merged by Andrew, but where I can find it? Could you give me git tree
> >>> address?
> >>
> >> Hi Simon,
> >>
> >> You can find all the physical memory hot-remove patches and related bugfix
> >> patches from the following url:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >
> > ~/linux-next$ git remote -v
> > origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > (fetch)
> > origin git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > (push)
> > ~/linux-next$ git branch
> > * akpm
> > master
> > ~/linux-next$ wc -l mm/memory_hotplug.c
> > 1173 mm/memory_hotplug.c
> >
> > I still can't find it. :(
>
> Hi Simon,
>
> It's weird, in my akpm git log, I can find the following commit.
>
> commit deed0460e01b3968f2cf46fb94851936535b7e0d
> Author: Tang Chen <tangchen@cn.fujitsu.com>
> Date: Sat Jan 19 11:07:13 2013 +1100
>
> memory-hotplug: do not allocate pgdat if it was not freed when offline.
>
> And there are 15 related patches following it. And above it, there are
> some more related bugfix
> from me and Andrew. They are all in -mm tree.
>
> This is what I did:
>
> $ git remote add next
> http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> $ git remote update next
> $ git checkout -b next-akpm remotes/next/akpm
>
> Please pull your tree and try again. :)
Got it. Thanks! :)
>
> Thanks. :)
>
>
> >
> >>
> >>
> >> Thanks. :)
> >>
> >> --
> >> 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>
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-23 12:29 ` Simon Jeons
(?)
@ 2013-01-25 13:17 ` Michal Hocko
-1 siblings, 0 replies; 48+ messages in thread
From: Michal Hocko @ 2013-01-25 13:17 UTC (permalink / raw)
To: Simon Jeons
Cc: Tang Chen, akpm, rientjes, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, wency,
hpa, linfeng, laijs, mgorman, yinghai, glommer, jiang.liu,
julian.calaby, sfr, x86, linux-mm, linux-kernel, linuxppc-dev,
linux-acpi
On Wed 23-01-13 06:29:31, Simon Jeons wrote:
> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> > Here are some bug fix patches for physical memory hot-remove. All these
> > patches are based on the latest -mm tree.
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >
> > And patch1 and patch3 are very important.
> > patch1: free compound pages when freeing memmap, otherwise the kernel
> > will panic the next time memory is hot-added.
> > patch3: the old way of freeing pagetable pages was wrong. We should never
> > split larger pages into small ones.
> >
> >
>
> Hi Tang,
>
> I remember your big physical memory hot-remove patchset has already
> merged by Andrew, but where I can find it? Could you give me git tree
> address?
Andrew tree is also mirrored into a git tree.
http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
It contains only Memory management patches on top of the last major
release (since-.X.Y branch).
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-25 13:17 ` Michal Hocko
0 siblings, 0 replies; 48+ messages in thread
From: Michal Hocko @ 2013-01-25 13:17 UTC (permalink / raw)
To: Simon Jeons
Cc: Tang Chen, akpm, rientjes, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, wency,
hpa, linfeng, laijs, mgorman, yinghai, glommer, jiang.liu,
julian.calaby, sfr, x86, linux-mm, linux-kernel, linuxppc-dev,
linux-acpi
On Wed 23-01-13 06:29:31, Simon Jeons wrote:
> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> > Here are some bug fix patches for physical memory hot-remove. All these
> > patches are based on the latest -mm tree.
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >
> > And patch1 and patch3 are very important.
> > patch1: free compound pages when freeing memmap, otherwise the kernel
> > will panic the next time memory is hot-added.
> > patch3: the old way of freeing pagetable pages was wrong. We should never
> > split larger pages into small ones.
> >
> >
>
> Hi Tang,
>
> I remember your big physical memory hot-remove patchset has already
> merged by Andrew, but where I can find it? Could you give me git tree
> address?
Andrew tree is also mirrored into a git tree.
http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
It contains only Memory management patches on top of the last major
release (since-.X.Y branch).
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-25 13:17 ` Michal Hocko
0 siblings, 0 replies; 48+ messages in thread
From: Michal Hocko @ 2013-01-25 13:17 UTC (permalink / raw)
To: Simon Jeons
Cc: Tang Chen, linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi,
isimatu.yasuaki, linfeng, mgorman, kosaki.motohiro, rientjes,
len.brown, jiang.liu, wency, julian.calaby, glommer, wujianguo,
yinghai, laijs, linux-kernel, minchan.kim, akpm, linuxppc-dev
On Wed 23-01-13 06:29:31, Simon Jeons wrote:
> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> > Here are some bug fix patches for physical memory hot-remove. All these
> > patches are based on the latest -mm tree.
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >
> > And patch1 and patch3 are very important.
> > patch1: free compound pages when freeing memmap, otherwise the kernel
> > will panic the next time memory is hot-added.
> > patch3: the old way of freeing pagetable pages was wrong. We should never
> > split larger pages into small ones.
> >
> >
>
> Hi Tang,
>
> I remember your big physical memory hot-remove patchset has already
> merged by Andrew, but where I can find it? Could you give me git tree
> address?
Andrew tree is also mirrored into a git tree.
http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
It contains only Memory management patches on top of the last major
release (since-.X.Y branch).
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-25 13:17 ` Michal Hocko
(?)
@ 2013-01-28 1:33 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-28 1:33 UTC (permalink / raw)
To: Michal Hocko
Cc: Simon Jeons, akpm, rientjes, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, wency,
hpa, linfeng, laijs, mgorman, yinghai, glommer, jiang.liu,
julian.calaby, sfr, x86, linux-mm, linux-kernel, linuxppc-dev,
linux-acpi
On 01/25/2013 09:17 PM, Michal Hocko wrote:
> On Wed 23-01-13 06:29:31, Simon Jeons wrote:
>> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
>>> Here are some bug fix patches for physical memory hot-remove. All these
>>> patches are based on the latest -mm tree.
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>>>
>>> And patch1 and patch3 are very important.
>>> patch1: free compound pages when freeing memmap, otherwise the kernel
>>> will panic the next time memory is hot-added.
>>> patch3: the old way of freeing pagetable pages was wrong. We should never
>>> split larger pages into small ones.
>>>
>>>
>>
>> Hi Tang,
>>
>> I remember your big physical memory hot-remove patchset has already
>> merged by Andrew, but where I can find it? Could you give me git tree
>> address?
>
> Andrew tree is also mirrored into a git tree.
> http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
>
> It contains only Memory management patches on top of the last major
> release (since-.X.Y branch).
Hi Michal,
I'm not sure I got your meaning. :)
In http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm,
I can find the following commit.
commit deed0460e01b3968f2cf46fb94851936535b7e0d
Author: Tang Chen <tangchen@cn.fujitsu.com>
Date: Sat Jan 19 11:07:13 2013 +1100
memory-hotplug: do not allocate pgdat if it was not freed when
offline.
This is one of memory hot-remove patches. Please try to update the
mirror tree,
and try to find the above commit.
Thanks. :)
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-28 1:33 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-28 1:33 UTC (permalink / raw)
To: Michal Hocko
Cc: Simon Jeons, akpm, rientjes, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, wency,
hpa, linfeng, laijs, mgorman, yinghai, glommer, jiang.liu,
julian.calaby, sfr, x86, linux-mm, linux-kernel, linuxppc-dev,
linux-acpi
On 01/25/2013 09:17 PM, Michal Hocko wrote:
> On Wed 23-01-13 06:29:31, Simon Jeons wrote:
>> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
>>> Here are some bug fix patches for physical memory hot-remove. All these
>>> patches are based on the latest -mm tree.
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>>>
>>> And patch1 and patch3 are very important.
>>> patch1: free compound pages when freeing memmap, otherwise the kernel
>>> will panic the next time memory is hot-added.
>>> patch3: the old way of freeing pagetable pages was wrong. We should never
>>> split larger pages into small ones.
>>>
>>>
>>
>> Hi Tang,
>>
>> I remember your big physical memory hot-remove patchset has already
>> merged by Andrew, but where I can find it? Could you give me git tree
>> address?
>
> Andrew tree is also mirrored into a git tree.
> http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
>
> It contains only Memory management patches on top of the last major
> release (since-.X.Y branch).
Hi Michal,
I'm not sure I got your meaning. :)
In http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm,
I can find the following commit.
commit deed0460e01b3968f2cf46fb94851936535b7e0d
Author: Tang Chen <tangchen@cn.fujitsu.com>
Date: Sat Jan 19 11:07:13 2013 +1100
memory-hotplug: do not allocate pgdat if it was not freed when
offline.
This is one of memory hot-remove patches. Please try to update the
mirror tree,
and try to find the above commit.
Thanks. :)
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-28 1:33 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-28 1:33 UTC (permalink / raw)
To: Michal Hocko
Cc: len.brown, linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi,
isimatu.yasuaki, linfeng, mgorman, kosaki.motohiro, rientjes,
Simon Jeons, jiang.liu, wency, julian.calaby, glommer, wujianguo,
yinghai, laijs, linux-kernel, minchan.kim, akpm, linuxppc-dev
On 01/25/2013 09:17 PM, Michal Hocko wrote:
> On Wed 23-01-13 06:29:31, Simon Jeons wrote:
>> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
>>> Here are some bug fix patches for physical memory hot-remove. All these
>>> patches are based on the latest -mm tree.
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>>>
>>> And patch1 and patch3 are very important.
>>> patch1: free compound pages when freeing memmap, otherwise the kernel
>>> will panic the next time memory is hot-added.
>>> patch3: the old way of freeing pagetable pages was wrong. We should never
>>> split larger pages into small ones.
>>>
>>>
>>
>> Hi Tang,
>>
>> I remember your big physical memory hot-remove patchset has already
>> merged by Andrew, but where I can find it? Could you give me git tree
>> address?
>
> Andrew tree is also mirrored into a git tree.
> http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
>
> It contains only Memory management patches on top of the last major
> release (since-.X.Y branch).
Hi Michal,
I'm not sure I got your meaning. :)
In http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm,
I can find the following commit.
commit deed0460e01b3968f2cf46fb94851936535b7e0d
Author: Tang Chen <tangchen@cn.fujitsu.com>
Date: Sat Jan 19 11:07:13 2013 +1100
memory-hotplug: do not allocate pgdat if it was not freed when
offline.
This is one of memory hot-remove patches. Please try to update the
mirror tree,
and try to find the above commit.
Thanks. :)
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-28 1:33 ` Tang Chen
(?)
@ 2013-01-28 8:15 ` Michal Hocko
-1 siblings, 0 replies; 48+ messages in thread
From: Michal Hocko @ 2013-01-28 8:15 UTC (permalink / raw)
To: Tang Chen
Cc: Simon Jeons, akpm, rientjes, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, wency,
hpa, linfeng, laijs, mgorman, yinghai, glommer, jiang.liu,
julian.calaby, sfr, x86, linux-mm, linux-kernel, linuxppc-dev,
linux-acpi
On Mon 28-01-13 09:33:49, Tang Chen wrote:
> On 01/25/2013 09:17 PM, Michal Hocko wrote:
> >On Wed 23-01-13 06:29:31, Simon Jeons wrote:
> >>On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> >>>Here are some bug fix patches for physical memory hot-remove. All these
> >>>patches are based on the latest -mm tree.
> >>>git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >>>
> >>>And patch1 and patch3 are very important.
> >>>patch1: free compound pages when freeing memmap, otherwise the kernel
> >>> will panic the next time memory is hot-added.
> >>>patch3: the old way of freeing pagetable pages was wrong. We should never
> >>> split larger pages into small ones.
> >>>
> >>>
> >>
> >>Hi Tang,
> >>
> >>I remember your big physical memory hot-remove patchset has already
> >>merged by Andrew, but where I can find it? Could you give me git tree
> >>address?
> >
> >Andrew tree is also mirrored into a git tree.
> >http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
> >
> >It contains only Memory management patches on top of the last major
> >release (since-.X.Y branch).
>
> Hi Michal,
>
> I'm not sure I got your meaning. :)
Well, the mirror tree gets updated when Andrew releases mmotm and quite
often even when mmots is released.
All patches in the mm section are applied.
> In http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm,
> I can find the following commit.
>
> commit deed0460e01b3968f2cf46fb94851936535b7e0d
> Author: Tang Chen <tangchen@cn.fujitsu.com>
> Date: Sat Jan 19 11:07:13 2013 +1100
>
> memory-hotplug: do not allocate pgdat if it was not freed when
> offline.
>
>
> This is one of memory hot-remove patches. Please try to update the
> mirror tree,
> and try to find the above commit.
That one is in my mirror tree as f48bf999 (memory-hotplug: do not
allocate pdgat if it was not freed when offline.).
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-28 8:15 ` Michal Hocko
0 siblings, 0 replies; 48+ messages in thread
From: Michal Hocko @ 2013-01-28 8:15 UTC (permalink / raw)
To: Tang Chen
Cc: Simon Jeons, akpm, rientjes, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, wency,
hpa, linfeng, laijs, mgorman, yinghai, glommer, jiang.liu,
julian.calaby, sfr, x86, linux-mm, linux-kernel, linuxppc-dev,
linux-acpi
On Mon 28-01-13 09:33:49, Tang Chen wrote:
> On 01/25/2013 09:17 PM, Michal Hocko wrote:
> >On Wed 23-01-13 06:29:31, Simon Jeons wrote:
> >>On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> >>>Here are some bug fix patches for physical memory hot-remove. All these
> >>>patches are based on the latest -mm tree.
> >>>git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >>>
> >>>And patch1 and patch3 are very important.
> >>>patch1: free compound pages when freeing memmap, otherwise the kernel
> >>> will panic the next time memory is hot-added.
> >>>patch3: the old way of freeing pagetable pages was wrong. We should never
> >>> split larger pages into small ones.
> >>>
> >>>
> >>
> >>Hi Tang,
> >>
> >>I remember your big physical memory hot-remove patchset has already
> >>merged by Andrew, but where I can find it? Could you give me git tree
> >>address?
> >
> >Andrew tree is also mirrored into a git tree.
> >http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
> >
> >It contains only Memory management patches on top of the last major
> >release (since-.X.Y branch).
>
> Hi Michal,
>
> I'm not sure I got your meaning. :)
Well, the mirror tree gets updated when Andrew releases mmotm and quite
often even when mmots is released.
All patches in the mm section are applied.
> In http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm,
> I can find the following commit.
>
> commit deed0460e01b3968f2cf46fb94851936535b7e0d
> Author: Tang Chen <tangchen@cn.fujitsu.com>
> Date: Sat Jan 19 11:07:13 2013 +1100
>
> memory-hotplug: do not allocate pgdat if it was not freed when
> offline.
>
>
> This is one of memory hot-remove patches. Please try to update the
> mirror tree,
> and try to find the above commit.
That one is in my mirror tree as f48bf999 (memory-hotplug: do not
allocate pdgat if it was not freed when offline.).
--
Michal Hocko
SUSE Labs
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-28 8:15 ` Michal Hocko
0 siblings, 0 replies; 48+ messages in thread
From: Michal Hocko @ 2013-01-28 8:15 UTC (permalink / raw)
To: Tang Chen
Cc: len.brown, linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi,
isimatu.yasuaki, linfeng, mgorman, kosaki.motohiro, rientjes,
Simon Jeons, jiang.liu, wency, julian.calaby, glommer, wujianguo,
yinghai, laijs, linux-kernel, minchan.kim, akpm, linuxppc-dev
On Mon 28-01-13 09:33:49, Tang Chen wrote:
> On 01/25/2013 09:17 PM, Michal Hocko wrote:
> >On Wed 23-01-13 06:29:31, Simon Jeons wrote:
> >>On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> >>>Here are some bug fix patches for physical memory hot-remove. All these
> >>>patches are based on the latest -mm tree.
> >>>git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
> >>>
> >>>And patch1 and patch3 are very important.
> >>>patch1: free compound pages when freeing memmap, otherwise the kernel
> >>> will panic the next time memory is hot-added.
> >>>patch3: the old way of freeing pagetable pages was wrong. We should never
> >>> split larger pages into small ones.
> >>>
> >>>
> >>
> >>Hi Tang,
> >>
> >>I remember your big physical memory hot-remove patchset has already
> >>merged by Andrew, but where I can find it? Could you give me git tree
> >>address?
> >
> >Andrew tree is also mirrored into a git tree.
> >http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary
> >
> >It contains only Memory management patches on top of the last major
> >release (since-.X.Y branch).
>
> Hi Michal,
>
> I'm not sure I got your meaning. :)
Well, the mirror tree gets updated when Andrew releases mmotm and quite
often even when mmots is released.
All patches in the mm section are applied.
> In http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm,
> I can find the following commit.
>
> commit deed0460e01b3968f2cf46fb94851936535b7e0d
> Author: Tang Chen <tangchen@cn.fujitsu.com>
> Date: Sat Jan 19 11:07:13 2013 +1100
>
> memory-hotplug: do not allocate pgdat if it was not freed when
> offline.
>
>
> This is one of memory hot-remove patches. Please try to update the
> mirror tree,
> and try to find the above commit.
That one is in my mirror tree as f48bf999 (memory-hotplug: do not
allocate pdgat if it was not freed when offline.).
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-22 11:42 ` Tang Chen
(?)
@ 2013-01-25 18:19 ` Toshi Kani
-1 siblings, 0 replies; 48+ messages in thread
From: Toshi Kani @ 2013-01-25 18:19 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> Here are some bug fix patches for physical memory hot-remove. All these
> patches are based on the latest -mm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> And patch1 and patch3 are very important.
> patch1: free compound pages when freeing memmap, otherwise the kernel
> will panic the next time memory is hot-added.
> patch3: the old way of freeing pagetable pages was wrong. We should never
> split larger pages into small ones.
>
>
> Lai Jiangshan (1):
> Bug-fix: mempolicy: fix is_valid_nodemask()
>
> Tang Chen (3):
> Bug fix: Do not split pages when freeing pagetable pages.
> Bug fix: Fix section mismatch problem of
> release_firmware_map_entry().
> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>
> Wen Congyang (1):
> Bug fix: consider compound pages when free memmap
>
> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
> drivers/firmware/memmap.c | 16 +++---
> mm/mempolicy.c | 36 +++++++----
> mm/sparse.c | 2 +-
> 4 files changed, 77 insertions(+), 125 deletions(-)
This patchset fixed a blocker panic I was hitting in my memory hot-plug
testing. Memory hotplug works fine with this patchset (for testing my
hotplug framework patchset :). For the series:
Tested-by: Toshi Kani <toshi.kani@hp.com>
Thanks,
-Toshi
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-25 18:19 ` Toshi Kani
0 siblings, 0 replies; 48+ messages in thread
From: Toshi Kani @ 2013-01-25 18:19 UTC (permalink / raw)
To: Tang Chen
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> Here are some bug fix patches for physical memory hot-remove. All these
> patches are based on the latest -mm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> And patch1 and patch3 are very important.
> patch1: free compound pages when freeing memmap, otherwise the kernel
> will panic the next time memory is hot-added.
> patch3: the old way of freeing pagetable pages was wrong. We should never
> split larger pages into small ones.
>
>
> Lai Jiangshan (1):
> Bug-fix: mempolicy: fix is_valid_nodemask()
>
> Tang Chen (3):
> Bug fix: Do not split pages when freeing pagetable pages.
> Bug fix: Fix section mismatch problem of
> release_firmware_map_entry().
> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>
> Wen Congyang (1):
> Bug fix: consider compound pages when free memmap
>
> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
> drivers/firmware/memmap.c | 16 +++---
> mm/mempolicy.c | 36 +++++++----
> mm/sparse.c | 2 +-
> 4 files changed, 77 insertions(+), 125 deletions(-)
This patchset fixed a blocker panic I was hitting in my memory hot-plug
testing. Memory hotplug works fine with this patchset (for testing my
hotplug framework patchset :). For the series:
Tested-by: Toshi Kani <toshi.kani@hp.com>
Thanks,
-Toshi
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-25 18:19 ` Toshi Kani
0 siblings, 0 replies; 48+ messages in thread
From: Toshi Kani @ 2013-01-25 18:19 UTC (permalink / raw)
To: Tang Chen
Cc: linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, jiang.liu,
wency, julian.calaby, glommer, wujianguo, yinghai, laijs,
linux-kernel, minchan.kim, akpm, linuxppc-dev
On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
> Here are some bug fix patches for physical memory hot-remove. All these
> patches are based on the latest -mm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>
> And patch1 and patch3 are very important.
> patch1: free compound pages when freeing memmap, otherwise the kernel
> will panic the next time memory is hot-added.
> patch3: the old way of freeing pagetable pages was wrong. We should never
> split larger pages into small ones.
>
>
> Lai Jiangshan (1):
> Bug-fix: mempolicy: fix is_valid_nodemask()
>
> Tang Chen (3):
> Bug fix: Do not split pages when freeing pagetable pages.
> Bug fix: Fix section mismatch problem of
> release_firmware_map_entry().
> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>
> Wen Congyang (1):
> Bug fix: consider compound pages when free memmap
>
> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
> drivers/firmware/memmap.c | 16 +++---
> mm/mempolicy.c | 36 +++++++----
> mm/sparse.c | 2 +-
> 4 files changed, 77 insertions(+), 125 deletions(-)
This patchset fixed a blocker panic I was hitting in my memory hot-plug
testing. Memory hotplug works fine with this patchset (for testing my
hotplug framework patchset :). For the series:
Tested-by: Toshi Kani <toshi.kani@hp.com>
Thanks,
-Toshi
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
2013-01-25 18:19 ` Toshi Kani
(?)
@ 2013-01-28 1:22 ` Tang Chen
-1 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-28 1:22 UTC (permalink / raw)
To: Toshi Kani
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On 01/26/2013 02:19 AM, Toshi Kani wrote:
> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
>> Here are some bug fix patches for physical memory hot-remove. All these
>> patches are based on the latest -mm tree.
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>>
>> And patch1 and patch3 are very important.
>> patch1: free compound pages when freeing memmap, otherwise the kernel
>> will panic the next time memory is hot-added.
>> patch3: the old way of freeing pagetable pages was wrong. We should never
>> split larger pages into small ones.
>>
>>
>> Lai Jiangshan (1):
>> Bug-fix: mempolicy: fix is_valid_nodemask()
>>
>> Tang Chen (3):
>> Bug fix: Do not split pages when freeing pagetable pages.
>> Bug fix: Fix section mismatch problem of
>> release_firmware_map_entry().
>> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>>
>> Wen Congyang (1):
>> Bug fix: consider compound pages when free memmap
>>
>> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
>> drivers/firmware/memmap.c | 16 +++---
>> mm/mempolicy.c | 36 +++++++----
>> mm/sparse.c | 2 +-
>> 4 files changed, 77 insertions(+), 125 deletions(-)
>
> This patchset fixed a blocker panic I was hitting in my memory hot-plug
> testing. Memory hotplug works fine with this patchset (for testing my
> hotplug framework patchset :). For the series:
Hi Toshi-san,
Thank you for testing. :)
>
> Tested-by: Toshi Kani<toshi.kani@hp.com>
>
> Thanks,
> -Toshi
>
>
>
>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-28 1:22 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-28 1:22 UTC (permalink / raw)
To: Toshi Kani
Cc: akpm, rientjes, len.brown, benh, paulus, cl, minchan.kim,
kosaki.motohiro, isimatu.yasuaki, wujianguo, wency, hpa, linfeng,
laijs, mgorman, yinghai, glommer, jiang.liu, julian.calaby, sfr,
x86, linux-mm, linux-kernel, linuxppc-dev, linux-acpi
On 01/26/2013 02:19 AM, Toshi Kani wrote:
> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
>> Here are some bug fix patches for physical memory hot-remove. All these
>> patches are based on the latest -mm tree.
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>>
>> And patch1 and patch3 are very important.
>> patch1: free compound pages when freeing memmap, otherwise the kernel
>> will panic the next time memory is hot-added.
>> patch3: the old way of freeing pagetable pages was wrong. We should never
>> split larger pages into small ones.
>>
>>
>> Lai Jiangshan (1):
>> Bug-fix: mempolicy: fix is_valid_nodemask()
>>
>> Tang Chen (3):
>> Bug fix: Do not split pages when freeing pagetable pages.
>> Bug fix: Fix section mismatch problem of
>> release_firmware_map_entry().
>> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>>
>> Wen Congyang (1):
>> Bug fix: consider compound pages when free memmap
>>
>> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
>> drivers/firmware/memmap.c | 16 +++---
>> mm/mempolicy.c | 36 +++++++----
>> mm/sparse.c | 2 +-
>> 4 files changed, 77 insertions(+), 125 deletions(-)
>
> This patchset fixed a blocker panic I was hitting in my memory hot-plug
> testing. Memory hotplug works fine with this patchset (for testing my
> hotplug framework patchset :). For the series:
Hi Toshi-san,
Thank you for testing. :)
>
> Tested-by: Toshi Kani<toshi.kani@hp.com>
>
> Thanks,
> -Toshi
>
>
>
>
--
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>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH Bug fix 0/5] Bug fix for physical memory hot-remove.
@ 2013-01-28 1:22 ` Tang Chen
0 siblings, 0 replies; 48+ messages in thread
From: Tang Chen @ 2013-01-28 1:22 UTC (permalink / raw)
To: Toshi Kani
Cc: linux-mm, paulus, hpa, cl, sfr, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, jiang.liu,
wency, julian.calaby, glommer, wujianguo, yinghai, laijs,
linux-kernel, minchan.kim, akpm, linuxppc-dev
On 01/26/2013 02:19 AM, Toshi Kani wrote:
> On Tue, 2013-01-22 at 19:42 +0800, Tang Chen wrote:
>> Here are some bug fix patches for physical memory hot-remove. All these
>> patches are based on the latest -mm tree.
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
>>
>> And patch1 and patch3 are very important.
>> patch1: free compound pages when freeing memmap, otherwise the kernel
>> will panic the next time memory is hot-added.
>> patch3: the old way of freeing pagetable pages was wrong. We should never
>> split larger pages into small ones.
>>
>>
>> Lai Jiangshan (1):
>> Bug-fix: mempolicy: fix is_valid_nodemask()
>>
>> Tang Chen (3):
>> Bug fix: Do not split pages when freeing pagetable pages.
>> Bug fix: Fix section mismatch problem of
>> release_firmware_map_entry().
>> Bug fix: Fix the doc format in drivers/firmware/memmap.c
>>
>> Wen Congyang (1):
>> Bug fix: consider compound pages when free memmap
>>
>> arch/x86/mm/init_64.c | 148 ++++++++++++++-------------------------------
>> drivers/firmware/memmap.c | 16 +++---
>> mm/mempolicy.c | 36 +++++++----
>> mm/sparse.c | 2 +-
>> 4 files changed, 77 insertions(+), 125 deletions(-)
>
> This patchset fixed a blocker panic I was hitting in my memory hot-plug
> testing. Memory hotplug works fine with this patchset (for testing my
> hotplug framework patchset :). For the series:
Hi Toshi-san,
Thank you for testing. :)
>
> Tested-by: Toshi Kani<toshi.kani@hp.com>
>
> Thanks,
> -Toshi
>
>
>
>
^ permalink raw reply [flat|nested] 48+ messages in thread