[libvirt] [PATCH 1/1] qemu: host NUMA hugepage policy without guest NUMA

[Martin Kletzander]

On Mon, Oct 17, 2016 at 03:45:09PM +1100, Sam Bobroff wrote:
>On Fri, Oct 14, 2016 at 10:19:42AM +0200, Martin Kletzander wrote:
>> On Fri, Oct 14, 2016 at 11:52:22AM +1100, Sam Bobroff wrote:
>> >I did look at the libnuma and cgroups approaches, but I was concerned they
>> >wouldn't work in this case, because of the way QEMU allocates memory when
>> >mem-prealloc is used: the memory is allocated in the main process, before the
>> >CPU threads are created. (This is based only on a bit of hacking and debugging
>> >in QEMU, but it does seem explain the behaviour I've seen so far.)
>> >
>>
>> But we use numactl before QEMU is exec()'d.
>
>Sorry, I jumped ahead a bit. I'll try to explain what I mean:
>
>I think the problem with using this method would be that the NUMA policy is
>applied to all allocations by QEMU, not just ones related to the memory
>backing. I'm not sure if that would cause a serious problem but it seems untidy,
>and it doesn't happen in other situations (i.e. with separate memory backend
>objects, QEMU sets up the policy specifically for each one and other
>allocations aren't affected, AFAIK).  Presumably, if memory were very
>restricted it could prevent the guest from starting.
>

Yes, it is, that's what <numatune><memory/> does if you don't have any
other (<memnode/>) specifics set.

>> >I think QEMU could be altered to move the preallocations into the VCPU
>> >threads but it didn't seem trivial and I suspected the QEMU community would
>> >point out that there was already a way to do it using backend objects.  Another
>> >option would be to add a -host-nodes parameter to QEMU so that the policy can
>> >be given without adding a memory backend object. (That seems like a more
>> >reasonable change to QEMU.)
>> >
>>
>> I think upstream won't like that, mostly because there is already a
>> way.  And that is using memory-backend object.  I think we could just
>> use that and disable changing it live.  But upstream will probably want
>> that to be configurable or something.
>
>Right, but isn't this already an issue in the cases where libvirt is already
>using memory backend objects and NUMA policy? (Or does libvirt already disable
>changing it live in those situations?)
>

It is.  I'm not trying to say libvirt is perfect.  There are bugs,
e.g. like this one.  The problem is that we tried to do *everything*,
but it's not currently possible.  I'm trying to explain how stuff works
now.  It definitely needs some fixing, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161018/877094ad/attachment-0001.sig>