From: Avi Kivity <avi@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
kvm@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH 0/3] KVM-userspace: add NUMA support for guests
Date: Mon, 01 Dec 2008 16:53:55 +0200 [thread overview]
Message-ID: <4933FA83.2050803@redhat.com> (raw)
In-Reply-To: <20081201144428.GF24079@redhat.com>
Daniel P. Berrange wrote:
>> The only problem is the default option for the host side, as libnuma
>> requires to explicitly name the nodes. Maybe make the pin: part _not_
>> optional? I would at least want to pin the memory, one could discuss
>> about the VCPUs...
>>
>
> I think keeping it optional makes things more flexible for people
> invoking KVM. If omitted, then query current CPU pinning to determine
> which host NUMA nodes to allocate from.
>
Well, -numa itself is optional. But yes, we could use the default cpu
affinity mask to derive the default host numa nodes.
> The topology exposed to a guest will likely be the same every time
> you launch a particular VM, while the guest<-> host pinning is a
> point in time decision according to current available resources.
> Thus some apps / users may find it more convenient to have a fixed set
> of args they always use to invoke the KVM process, and instead control
> placement during the fork/exec'ing of KVM by explicitly calling
> sched_setaffinity or using numactl to launch. It should be easy enough
> to use sched_getaffinity to query current pining and from that determine
> appropriate NUMA nodes, if they leave out the pin=XXXX arg.
>
I agree, nice idea.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2008-12-01 14:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-27 22:23 [PATCH 0/3] KVM-userspace: add NUMA support for guests Andre Przywara
2008-11-28 8:14 ` Andi Kleen
2008-11-29 18:43 ` Avi Kivity
2008-11-29 20:10 ` Andi Kleen
2008-11-29 20:35 ` Avi Kivity
2008-11-30 15:41 ` Andi Kleen
2008-11-30 15:38 ` Avi Kivity
2008-11-30 16:05 ` Andi Kleen
2008-11-30 16:38 ` Avi Kivity
2008-11-30 17:04 ` Andi Kleen
2008-11-30 17:11 ` Avi Kivity
2008-11-30 17:42 ` Andi Kleen
2008-11-30 18:07 ` Avi Kivity
2008-11-30 18:55 ` Andi Kleen
2008-11-30 19:11 ` Skywing
2008-11-30 20:08 ` Avi Kivity
2008-11-30 20:07 ` Avi Kivity
2008-11-30 21:41 ` Andi Kleen
2008-11-30 21:50 ` Avi Kivity
2008-11-30 22:08 ` Skywing
2008-11-28 10:40 ` Daniel P. Berrange
2008-11-29 18:29 ` Avi Kivity
2008-12-01 14:15 ` Andre Przywara
2008-12-01 14:29 ` Avi Kivity
2008-12-01 15:27 ` Anthony Liguori
2008-12-01 15:34 ` Anthony Liguori
2008-12-01 15:37 ` Avi Kivity
2008-12-01 15:49 ` Anthony Liguori
2008-12-01 14:44 ` Daniel P. Berrange
2008-12-01 14:53 ` Avi Kivity [this message]
2008-12-01 15:18 ` Anthony Liguori
2008-12-01 15:35 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4933FA83.2050803@redhat.com \
--to=avi@redhat.com \
--cc=ak@suse.de \
--cc=andre.przywara@amd.com \
--cc=berrange@redhat.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.