From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/3][RFC] NUMA: add host side pinning Date: Tue, 29 Jun 2010 12:46:56 +0300 Message-ID: <4C29C110.5040404@redhat.com> References: <1277327377-29629-1-git-send-email-andre.przywara@amd.com> <4C2288DD.3020207@codemonkey.ws> <865764AB-4E51-4ED4-8832-AED6A237A9D3@suse.de> <4C233A6D.7030805@amd.com> <4C233DAB.60106@redhat.com> <4C2342D1.4090103@amd.com> <4C234493.2050408@redhat.com> <4C28CBC5.80109@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Przywara , Alexander Graf , "kvm@vger.kernel.org" To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45996 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754554Ab0F2JrD (ORCPT ); Tue, 29 Jun 2010 05:47:03 -0400 In-Reply-To: <4C28CBC5.80109@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 06/28/2010 07:20 PM, Anthony Liguori wrote: >> >>>>> To avoid this I'd like to see the pinning done from within QEMU. I >>>>> am not sure whether calling numactl via system() and friends is >>>>> OK, I'd prefer to run the syscalls directly (like in patch 3/3) >>>>> and pull the necessary options into the -numa pin,... command >>>>> line. We could mimic numactl's syntax here. >>>> >>>> Definitely not use system(), but IIRC numactl has a library interface? >>> Right, that is what I include in patch 3/3 and use. I got the >>> impression Anthony wanted to avoid reimplementing parts of numactl, >>> especially enabling the full flexibility of the command line >>> interface (like specifying nodes, policies and interleaving). >>> I want QEMU to use the library and pull the necessary options into >>> the -numa pin,... parsing, even if this means duplicating numactl >>> functionality. >>> >> >> I agree with that. It's a lot easier to use a single tool than to >> try to integrate things yourself, the unix tradition of grep | sort | >> uniq -c | sort -n notwithstanding. Especially when one of the tools >> is qemu. > > > I could disagree more here. This is why we don't support CPU pinning > and instead provide PID information for each VCPU thread. Good point. That also allows setting priority, etc. > > The folks that want to use pinning are not notice users. They are not > going to be happy unless you can make full use of existing tools. > That means replicating all of numactl's functionality (which is not > what the current patches do) or enable numactl to be used with a guest. > Yeah. Unfortunately, that also forces us to use non-anonymous memory. So it isn't just where to put the functionality, it also has side effects. -- error compiling committee.c: too many arguments to function