From: David Vrabel <david.vrabel@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Elena Ufimtseva <ufimtseva@gmail.com>,
<xen-devel@lists.xenproject.org>, <boris.ostrovsky@oracle.com>,
<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
<x86@kernel.org>, <akpm@linux-foundation.org>,
<tangchen@cn.fujitsu.com>, <wency@cn.fujitsu.com>,
<ian.campbell@citrix.com>, <stefano.stabellini@eu.citrix.com>,
<mukesh.rathor@oracle.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND v2 2/2] xen: enable vnuma for PV guest
Date: Tue, 19 Nov 2013 15:55:06 +0000 [thread overview]
Message-ID: <528B89DA.2080504@citrix.com> (raw)
In-Reply-To: <20131119151924.GC5790@phenom.dumpdata.com>
On 19/11/13 15:19, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 19, 2013 at 02:56:41PM +0000, David Vrabel wrote:
>> The relevant bits in dummy_numa_init are in the error path of
>> xen_numa_init().
>
> That seems the wrong place to do it. The top layer calls
> in each of the numa implementations and then falls back to
> the dummy.
Think of it as not the dummy, but Xen setting the NUMA configuration up
with only a single node.
The useful bits in dummy_numa_init() are two calls to standard functions
for use by *_numa_init() calls so it just seems easier all round to just
call then directly than add a dependancy on dummy_numa_init().
> Calling from within the implementation on something that is eventually
> done on the upper level already is not right.
>From the point of view of the caller, it does the right thing. NUMA is
setup.
>> I do think this approach (using the provided API to setup the single
>> (dummy) node), is preferable to calling dummy_numa_init().
>
> Doesn't it do the same thing? And also what about if you the user
> provides fakenuma?
I don't know what "fakenuma" is refering to.
>> If I thought the hypervisor ABI was finalized, I'd be happy with this
>> series as-is -- the remaining issues are superficial.
>
> That reads to me as an Ack, but I know you like to have it stated
> explicitly - so could you state the proper tag please?
"If I thought the hypervisor ABI was finalized..." is a pretty big "if"
so I have deliberately /not/ given an ack or a reviewed tag but I've
tried to be clear than I think the Linux side is now good enough (except
for any changes for any updates to the hypervisor ABI).
David
next prev parent reply other threads:[~2013-11-19 15:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 21:58 [PATCH RESEND v2 0/2] xen: vnuma introduction for pv guest Elena Ufimtseva
2013-11-18 21:58 ` [PATCH RESEND v2 1/2] xen: vnuma support for PV guests running as domU Elena Ufimtseva
2013-11-18 21:58 ` Elena Ufimtseva
2013-11-19 11:53 ` David Vrabel
2013-11-19 11:53 ` David Vrabel
2013-11-18 21:58 ` [PATCH RESEND v2 2/2] xen: enable vnuma for PV guest Elena Ufimtseva
2013-11-19 11:54 ` David Vrabel
2013-11-19 11:54 ` David Vrabel
2013-11-19 14:16 ` Konrad Rzeszutek Wilk
2013-11-19 14:16 ` Konrad Rzeszutek Wilk
2013-11-19 14:35 ` David Vrabel
2013-11-19 14:35 ` David Vrabel
2013-11-19 14:46 ` Konrad Rzeszutek Wilk
2013-11-19 14:56 ` David Vrabel
2013-11-19 15:19 ` Konrad Rzeszutek Wilk
2013-11-19 15:55 ` David Vrabel [this message]
2013-11-19 16:20 ` Konrad Rzeszutek Wilk
2013-11-19 16:20 ` Konrad Rzeszutek Wilk
2013-11-19 15:55 ` David Vrabel
2013-11-19 15:19 ` Konrad Rzeszutek Wilk
2013-11-23 16:48 ` [Xen-devel] " Dario Faggioli
2013-11-23 16:48 ` Dario Faggioli
2013-11-19 14:56 ` David Vrabel
2013-11-19 14:46 ` Konrad Rzeszutek Wilk
2013-11-18 21:58 ` Elena Ufimtseva
2013-11-19 7:18 ` [Xen-devel] [PATCH RESEND v2 0/2] xen: vnuma introduction for pv guest Dario Faggioli
2013-11-19 7:18 ` Dario Faggioli
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=528B89DA.2080504@citrix.com \
--to=david.vrabel@citrix.com \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=hpa@zytor.com \
--cc=ian.campbell@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mukesh.rathor@oracle.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tangchen@cn.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=ufimtseva@gmail.com \
--cc=wency@cn.fujitsu.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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.