qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA bi


From: Chris Wright
Subject: Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
Date: Mon, 21 Nov 2011 14:50:10 -0800
User-agent: Mutt/1.5.20 (2009-08-17)

* Peter Zijlstra (address@hidden) wrote:
> On Mon, 2011-11-21 at 21:30 +0530, Bharata B Rao wrote:
> > 
> > In the original post of this mail thread, I proposed a way to export
> > guest RAM ranges (Guest Physical Address-GPA) and their corresponding host
> > host virtual mappings (Host Virtual Address-HVA) from QEMU (via QEMU 
> > monitor).
> > The idea was to use this GPA to HVA mappings from tools like libvirt to bind
> > specific parts of the guest RAM to different host nodes. This needed an
> > extension to existing mbind() to allow binding memory of a process(QEMU) 
> > from a
> > different process(libvirt). This was needed since we wanted to do all this 
> > from
> > libvirt.
> > 
> > Hence I was coming from that background when I asked for extending
> > ms_mbind() to take a tid parameter. If QEMU community thinks that NUMA
> > binding should all be done from outside of QEMU, it is needed, otherwise
> > what you have should be sufficient. 
> 
> That's just retarded, and no you won't get such extentions. Poking at
> another process's virtual address space is just daft. Esp. if there's no
> actual reason for it.

Need to separate the binding vs the policy mgmt.  The policy mgmt could
still be done outside, whereas the binding could still be done from w/in
QEMU.  A simple monitor interface to rebalance vcpu memory allcoations
to different nodes could very well schedule vcpu thread work in QEMU.

So, I agree, even if there is some external policy mgmt, it could still
easily work w/ QEMU to use Peter's proposed interface.

thanks,
-chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]