From: Dario Faggioli <dario.faggioli@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Yechen Li <lccycc123@gmail.com>, <xen-devel@lists.xen.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH v1][RFC] drivers/xen, balloon driver numa support in kernel
Date: Mon, 12 Aug 2013 22:14:43 +0200 [thread overview]
Message-ID: <1376338483.15390.271.camel@Solace> (raw)
In-Reply-To: <52092CF9.4050006@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]
On lun, 2013-08-12 at 19:44 +0100, David Vrabel wrote:
> On 12/08/13 15:13, Yechen Li wrote:
> > This small patch adds numa support for balloon driver. Kernel version: 3.11-rc5
> > It's just a RFC version, since I'm waiting for the interface of numa topology.
> > The balloon driver will read arguments from xenstore: /local/domain/(id)/memory
> > /target_nid, and settle the memory increase/decrease operation on specified
> > p-nodeID.
>
> Its is difficult to review an ABI change without any documentation for
> the new ABI.
>
Indeed.
> I would also like to see a design document explaining the overall
> approach planned to be used here. It's not clear why explicitly
> specifying nodes is preferable to (e.g.) the guest releasing/populating
> evenly across all its nodes (this would certainly be better for the guest).
>
I see what you mean. Personally, I think they're different things. There
might be the need, from the host system administrator, to make as much
room as possible on one (or perhaps a few) nodes, in which case, the
possibility of specifying that explicitly would be a plus.
That would allow --if used wisely, I agree with you on this-- for better
resource utilization, in the long run.
In absence of this information, it is probably true that the guest would
benefit from a more even approach. What we want to achieve here,
however, is as follows: suppose that a virtual NUMA enabled guest (i.e.,
a guest with a virtual NUMA topology), has guest page X, which is on
virtual node g1 in the guest itself, backed by a frame from host node
h0. Well, we really would like to try having page X always backed by a
frame on host node h1, even after ballooning down and up.
> It seems like unless this is used carefully, all VMs will end up with
> suboptimal memory layouts as they are repeatedly balloon up and down to
> satisfy the whims of the latest VM being started etc.
>
I'm not sure I see entirely what you mean, but for sure I repeat that I
agree that more information about the design and intended usage patterns
are needed... Let's see whether Yechen is up for providing that. :-)
Thanks for having a look anyway,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-08-12 20:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 14:13 [PATCH v1][RFC] drivers/xen, balloon driver numa support in kernel Yechen Li
2013-08-12 18:44 ` [Xen-devel] " David Vrabel
2013-08-12 20:14 ` Dario Faggioli
2013-08-12 20:14 ` Dario Faggioli [this message]
2013-08-12 18:44 ` David Vrabel
2013-08-12 20:26 ` Dario Faggioli
2013-08-13 12:46 ` Konrad Rzeszutek Wilk
2013-08-13 12:46 ` Konrad Rzeszutek Wilk
2013-08-13 12:53 ` David Vrabel
2013-08-13 13:18 ` Konrad Rzeszutek Wilk
2013-08-13 13:18 ` Konrad Rzeszutek Wilk
2013-08-13 19:00 ` Dario Faggioli
2013-08-13 19:00 ` [Xen-devel] " 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=1376338483.15390.271.camel@Solace \
--to=dario.faggioli@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=lccycc123@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xen.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.