From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/3] KVM-userspace: add NUMA support for guests Date: Mon, 01 Dec 2008 16:53:55 +0200 Message-ID: <4933FA83.2050803@redhat.com> References: <492F1DD9.8030901@amd.com> <49318A10.7080801@redhat.com> <4933F177.5040802@amd.com> <20081201144428.GF24079@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Przywara , kvm@vger.kernel.org, Andi Kleen To: "Daniel P. Berrange" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36392 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751322AbYLAOyC (ORCPT ); Mon, 1 Dec 2008 09:54:02 -0500 In-Reply-To: <20081201144428.GF24079@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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