Re: [PATCH part1 v6 4/6] x86/mem-hotplug: Support initialize page tables in bottom-up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2013-10-09 at 14:14 -0700, 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.

That's a good idea!  It will work just fine if firmware is written in
such a way.  However, since the most (if not all) firmware integrates
and exposes all memory at boot, we still need to support this regular
scenario as well.

> The whole reason for VMs wanting this is because ballooning doesn't
> scale with regards to metadata.

Agreed.

Thanks,
-Toshi


--
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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]