Hello Peter, On 10/10/2013 05:14 AM, H. Peter Anvin wrote: > On 10/09/2013 02:11 PM, Tejun Heo wrote: >> Hello, Toshi. >> >> On Wed, Oct 09, 2013 at 02:58:31PM -0600, Toshi Kani wrote: >>> Let's not assume that memory hotplug is always a niche feature for huge >>> & special systems. It may be a niche to begin with, but it could be >>> supported on VMs, which allows anyone to use. Vasilis has been working >>> on KVM to support memory hotplug. >> >> I'm not saying hotplug will always be niche. I'm saying the approach >> we're currently taking is. It seems fairly inflexible to hang the >> whole thing on NUMA nodes. What does the planned kvm support do? >> Splitting SRAT nodes so that it can do both actual NUMA node >> distribution and hotplug granuliarity? IIRC I asked a couple times >> what the long term plan was for this feature and there doesn't seem to >> be any road map for this thing to become a full solution. Unless I >> misunderstood, this is more of "let's put out the fire as there >> already are (or gonna be) machines which can do it" kinda thing, which >> is fine too. My point is that it doesn't make a lot of sense to >> change boot sequence invasively to accomodate that. >> > > I would also argue that in the VM scenario -- and arguable even in the > hardware scenario -- the right thing is to not expose the flexible > memory in the e820/EFI tables, and instead have it hotadded (possibly > *immediately* so) on boot. This avoids both the boot time funnies as > well as the scaling issues with metadata. > So in this kind of scenario, hotpluggable memory will not be detected at boot time, and admin should not use this movable_node boot option and the kernel will act as before, using top-down allocation always. -- Thanks. Zhang Yanfei -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>