[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <517A41C1.1010208@cn.fujitsu.com>
Date: Fri, 26 Apr 2013 16:58:41 +0800
From: Tang Chen <tangchen@...fujitsu.com>
To: Yinghai Lu <yinghai@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>, Thomas Renninger <trenn@...e.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 00/22] x86, ACPI, numa: Parse numa info early
Hi Yinghai,
It has been a long time since this patch-set was sent. I think we need to
do something to push it.
In my understanding, this patch-set did 2 things.
1. Parse numa info earlier, some improvements for
ACPI_INITRD_TABLE_OVERRIDE.
(patch1 ~ patch20)
2. Allocate pagetable in local node at boot time. (patch21 ~ patch22)
As you know, the current implement of memory hot-remove is not based on
putting pagetable in local node. If we put pagetable in local node at boot
time, the memory hot-remove won't be able to work as before.
I agree that this should be fixed. But we have the following two reasons to
push "Parse numa info earlier" part first, and improve the performance
later.
1. patch21 and patch22 only affect the performance, not the functionality.
I think we can make memory hot-remove work in the kernel, and than
improve
the performance.
2. Besides putting pagetable in local node at boot time, there are many
other
things need to do. I'm working on improving hot-add code to allocate
pagetable
and vmemmap in local node, and improving hot-remove code to support
freeing
this kind of memory.
So in order to push this patch-set and memory hot-remove functionality,
shall we divide this patch-set into 2 steps:
1. Push patch1 ~ patch20, and I'll push the remaining memory hot-remove
work together.
2. Merge your "putting pagetable in local node" work with the
performance improvement
work I'm doing, and improve the performance.
How do you think ?
BTW, I'm testing your patch-set, and will give a result next week.
I can also help to rebase it if you like.
Thanks. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists