From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBe7p-0003gx-KV for qemu-devel@nongnu.org; Sat, 13 Dec 2008 18:42:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBe7o-0003ga-JT for qemu-devel@nongnu.org; Sat, 13 Dec 2008 18:42:21 -0500 Received: from [199.232.76.173] (port=60787 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBe7o-0003gQ-BD for qemu-devel@nongnu.org; Sat, 13 Dec 2008 18:42:20 -0500 Received: from an-out-0708.google.com ([209.85.132.242]:4975) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBe7o-0005CN-0F for qemu-devel@nongnu.org; Sat, 13 Dec 2008 18:42:20 -0500 Received: by an-out-0708.google.com with SMTP id c38so1019741ana.37 for ; Sat, 13 Dec 2008 15:42:17 -0800 (PST) Message-ID: <49444855.3060605@codemonkey.ws> Date: Sat, 13 Dec 2008 17:42:13 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4940F9B5.9080206@amd.com> <49427CE1.4050108@codemonkey.ws> <49438371.9060304@redhat.com> <4943EE6C.8030508@amd.com> In-Reply-To: <4943EE6C.8030508@amd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 2/3] NUMA: promoting NUMA topology to BIOS and pin guest memory Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andre Przywara Cc: Avi Kivity , qemu-devel@nongnu.org Andre Przywara wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >>> >>> At this point, I'm okay with introducing the libnuma dependency for >>> memory pinning. I'm not sure I think we should even present this as >>> a command line option though. I think the command line option >>> should just specify the NUMA topology and then we should use a >>> monitor command for pinning (as you do on your next patch). >> >> It's helpful to have static pinning from the command line. That's >> useful for quick tests for those of us who don't use management >> interfaces. >> >> Since the monitor and command line can share code, there shouldn't be >> any cost to this. > ACK. Actually I'd had to add code to prevent pinning from the command > line. I think this doesn't hurt, if you use virtualization for > partitioning (where a NUMA architecture can actually help you, because > guests don't compete will all other guests for the memory bandwidth), > it is quite helpful to specify everything at the beginning. The thing that makes me uneasy about it is the fact that it's part of the base numa syntax. This combination of guest configuration and host configuration seems less than optimal to me. This isn't something that bothers me that much and won't keep me from applying the patches. Regards, Anthony Liguori > Here even UP guest can take advantage: > -numa 1,pin:1 > > Regards, > Andre. >