From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH 0/5] [POST-4.0]: RFC: HVM NUMA guest support Date: Wed, 7 Apr 2010 11:03:00 +0200 Message-ID: <4BBC4A44.1070004@amd.com> References: <4B6B4126.2050508@amd.com> <4B83A58D.4000901@amd.com> <4BB90780.9050202@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Cui, Dexuan" Cc: "xen-devel@lists.xensource.com" , Dulloor , Keir Fraser List-Id: xen-devel@lists.xenproject.org Cui, Dexuan wrote: > Andre Przywara wrote: >> Cui, Dexuan wrote: >>> Hi Andre, will you re-post your patches? >> Yes, I will do in the next days. I plan to add the missing automatic >> assignment patch before posting. > Glad to know this. > BTW: To support PV NUMA, on this Monday, Dulloor posted some paches that change libxc and the hypervisor, too. Yes, I saw them. I am about to look at them more thoroughly. Will get back to you later on this. >>> And we should add one more option "uniform_nodes" -- this boolean >>> option's default value can be True, meaning if we can't construct >>> uniform nodes to guest(e.g., on the related host node, no enough >>> memory as expected can be allocated to the guest), the guest >>> creation should fail. This option is useful to users who want >>> predictable guest performance. >> I agree that we need to avoid missing user influence, although I'd >> prefer to have the word "strict" somewhere in this name. As I wrote in >> one my earlier mails, I'd opt for a single option describing the >> policy, the "strict" meaning could be integrated in there: >> numa_policy="strict|uniform|automatic|none|single|..." > Hi Andre, > I think this looks too complex for the first simple implementation and it's very likely a real user will be bewildered. :-) > I think ideally we can have 2 options: > guest_nodes=n > uniform_nodes=True|False (the default is True) I agree on the guest_nodes, but I want to avoid a bunch of "single bit" options that we need to carry on later. Lets introduce a numa_policy option and only implement the words we need for now, e.g. "strict" (equivalent to "uniform_nodes=True") and "automatic" (aka "uniform_nodes=False"). The list I gave above was just a quick example of _possible_ words, it was neither exhaustive or non-redundant. Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712