Hi Simon,
On 01/31/2013 04:48 PM, Simon Jeons wrote:
Hi Tang,
On Thu, 2013-01-31 at 15:10 +0800, Tang Chen wrote:
1. IIUC, there is a button on machine which supports hot-remove memory,
then what's the difference between press button and echo to /sys?
No important difference, I think. Since I don't have the machine you are
saying, I cannot surely answer you. :)
AFAIK, pressing the button means trigger the hotplug from hardware, sysfs
is just another entrance. At last, they will run into the same code.
2. Since kernel memory is linear mapping(I mean direct mapping part),
why can't put kernel direct mapping memory into one memory device, and
other memory into the other devices?
We cannot do that because in that way, we will lose NUMA performance.
If you know NUMA, you will understand the following example:
node0: node1:
cpu0~cpu15 cpu16~cpu31
memory0~memory511 memory512~memory1023
cpu16~cpu31 access memory16~memory1023 much faster than memory0~memory511.
If we set direct mapping area in node0, and movable area in node1, then
the kernel code running on cpu16~cpu31 will have to access
memory0~memory511.
This is a terrible performance down.
As you know x86_64 don't need
highmem, IIUC, all kernel memory will linear mapping in this case. Is my
idea available? If is correct, x86_32 can't implement in the same way
since highmem(kmap/kmap_atomic/vmalloc) can map any address, so it's
hard to focus kernel memory on single memory device.
Sorry, I'm not quite familiar with x86_32 box.
3. In current implementation, if memory hotplug just need memory
subsystem and ACPI codes support? Or also needs firmware take part in?
Hope you can explain in details, thanks in advance. :)
We need firmware take part in, such as SRAT in ACPI BIOS, or the firmware
based memory migration mentioned by Liu Jiang.
So far, I only know this. :)
4. What's the status of memory hotplug? Apart from can't remove kernel
memory, other things are fully implementation?
I think the main job is done for now. And there are still bugs to fix.
And this functionality is not stable.
Thanks. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
