All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <raistlin.df@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v6 02/23] xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE
Date: Wed, 04 Mar 2015 13:51:26 +0100	[thread overview]
Message-ID: <1425473486.2614.53.camel@gmail.com> (raw)
In-Reply-To: <54F58505020000780006582B@mail.emea.novell.com>


[-- Attachment #1.1: Type: text/plain, Size: 1599 bytes --]

On Tue, 2015-03-03 at 08:55 +0000, Jan Beulich wrote:
> >>> On 03.03.15 at 04:42, <raistlin.df@gmail.com> wrote:

> > Indeed. It tells Xen: <<hey Xen, toolstack here: we either don't care or
> > could not come up with any sane vnode-to-pnode mapping, please figure
> > that out yourself>>.
> > 
> > That makes the code, IMO, simpler at any level. In fact, at Xen level,
> > there is a default way to deal with the situation (the striping)
> > already. At the toolstack level, we can only care about trying to come
> > up with some super-cool and super-good (for performance) configuration
> > and just give up, if anything like what David and Andrew said occurs.
> 
> See my earlier reply - the tool stack at least giving hints to the
> hypervisor in such a case would likely still be better (for the final
> result) than leaving it entirely up to the hypervisor: "No node"
> really means allocate from anywhere, whereas some specific
> node passed in still allows the hypervisor to find second best fits
> when having to fall back.
> 
Yes, at the cost of more complex algorithms, both in the hypervisor (as
you say in your other email) and in the toolstack. HV may not be an
issue, toolstack, I'm not sure...

I already have a draft implementation for that, which I'll rebase and
submit on top of Wei's series, as soon as that one will be in.

I think I agree with Wei when he says that it's probably better to drop
the argument for now... We'll see later whether we really need a way to
tell NO_NODE to the hypervisor, and add it then, or not.

Regards,
Dario



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2015-03-04 12:51 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-26 15:55 [PATCH v6 00/23] Virtual NUMA for PV and HVM Wei Liu
2015-02-26 15:55 ` [PATCH v6 01/23] xen: factor out construct_memop_from_reservation Wei Liu
2015-02-27 10:57   ` Andrew Cooper
2015-02-26 15:55 ` [PATCH v6 02/23] xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE Wei Liu
2015-02-27 11:38   ` Andrew Cooper
2015-02-27 16:42   ` Jan Beulich
2015-02-27 16:51     ` Wei Liu
2015-02-27 16:52       ` Andrew Cooper
2015-03-02  7:04         ` Jan Beulich
2015-03-02 15:30           ` Ian Campbell
2015-03-02 15:38             ` Wei Liu
2015-03-02 15:51               ` Jan Beulich
2015-03-02 16:08                 ` Wei Liu
2015-03-02 16:27                   ` Jan Beulich
2015-03-02 16:39                     ` Wei Liu
2015-03-02 16:50                       ` Jan Beulich
2015-03-02 17:00                         ` Wei Liu
2015-03-03  7:44                           ` Jan Beulich
2015-03-03 11:08                             ` Wei Liu
2015-03-02 17:01                         ` Andrew Cooper
2015-03-02 17:26                           ` Jan Beulich
2015-03-02 17:34                             ` David Vrabel
2015-03-02 17:43                               ` Andrew Cooper
2015-03-02 17:48                                 ` David Vrabel
2015-03-02 17:52                                   ` Ian Campbell
2015-03-02 18:19                                     ` Andrew Cooper
2015-03-03  3:42                                       ` Dario Faggioli
2015-03-03  8:55                                         ` Jan Beulich
2015-03-04 12:51                                           ` Dario Faggioli [this message]
2015-03-03  7:56                                       ` Jan Beulich
2015-03-03  7:36                               ` Jan Beulich
2015-02-26 15:55 ` [PATCH v6 03/23] xen: make two memory hypercalls vNUMA-aware Wei Liu
2015-02-27 16:59   ` Jan Beulich
2015-02-27 17:03     ` Wei Liu
2015-02-26 15:55 ` [PATCH v6 04/23] libxc: duplicate snippet to allocate p2m_host array Wei Liu
2015-03-02 15:26   ` Ian Campbell
2015-03-02 15:33     ` Wei Liu
2015-03-02 16:18       ` Ian Campbell
2015-03-02 16:45         ` Konrad Rzeszutek Wilk
2015-03-02 16:46     ` Konrad Rzeszutek Wilk
2015-02-26 15:55 ` [PATCH v6 05/23] libxc: add p2m_size to xc_dom_image Wei Liu
2015-03-02 15:28   ` Ian Campbell
2015-02-26 15:55 ` [PATCH v6 06/23] libxc: allocate memory with vNUMA information for PV guest Wei Liu
2015-03-02 15:36   ` Ian Campbell
2015-02-26 15:55 ` [PATCH v6 07/23] libxl: introduce vNUMA types Wei Liu
2015-02-26 15:55 ` [PATCH v6 08/23] libxl: add vmemrange to libxl__domain_build_state Wei Liu
2015-02-26 15:55 ` [PATCH v6 09/23] libxl: introduce libxl__vnuma_config_check Wei Liu
2015-03-02 15:34   ` Ian Campbell
2015-03-02 15:50     ` Wei Liu
2015-03-03  3:52     ` Dario Faggioli
2015-02-26 15:55 ` [PATCH v6 10/23] libxl: x86: factor out e820_host_sanitize Wei Liu
2015-02-26 15:55 ` [PATCH v6 11/23] libxl: functions to build vmemranges for PV guest Wei Liu
2015-02-26 16:39   ` Dario Faggioli
2015-03-02 15:41   ` Ian Campbell
2015-03-02 17:52     ` Wei Liu
2015-02-26 15:55 ` [PATCH v6 12/23] libxl: build, check and pass vNUMA info to Xen " Wei Liu
2015-02-26 15:55 ` [PATCH v6 13/23] libxc: indentation change to xc_hvm_build_x86.c Wei Liu
2015-02-26 15:55 ` [PATCH v6 14/23] libxc: allocate memory with vNUMA information for HVM guest Wei Liu
2015-03-02 15:43   ` Ian Campbell
2015-02-26 15:55 ` [PATCH v6 15/23] libxl: build, check and pass vNUMA info to Xen " Wei Liu
2015-03-02 15:44   ` Ian Campbell
2015-02-26 15:55 ` [PATCH v6 16/23] libxl: disallow memory relocation when vNUMA is enabled Wei Liu
2015-03-02 15:46   ` Ian Campbell
2015-02-26 15:56 ` [PATCH v6 17/23] libxl: define LIBXL_HAVE_VNUMA Wei Liu
2015-02-27 13:46   ` Dario Faggioli
2015-02-26 15:56 ` [PATCH v6 18/23] libxlu: rework internal representation of setting Wei Liu
2015-02-26 15:56 ` [PATCH v6 19/23] libxlu: nested list support Wei Liu
2015-02-26 15:56 ` [PATCH v6 20/23] libxlu: record line and column number when parsing values Wei Liu
2015-03-06 11:36   ` Ian Jackson
2015-03-06 12:03     ` Wei Liu
2015-03-06 14:30       ` Ian Jackson
2015-03-06 16:11         ` Wei Liu
2015-03-06 16:57           ` Wei Liu
2015-02-26 15:56 ` [PATCH v6 21/23] libxlu: introduce new APIs Wei Liu
2015-03-06 11:40   ` Ian Jackson
2015-02-26 15:56 ` [PATCH v6 22/23] xl: introduce xcalloc Wei Liu
2015-03-02 15:51   ` Ian Campbell
2015-02-26 15:56 ` [PATCH v6 23/23] xl: vNUMA support Wei Liu
2015-02-27 16:17   ` Dario Faggioli
2015-03-02 15:59   ` Ian Campbell
2015-03-02 16:31     ` Wei Liu

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=1425473486.2614.53.camel@gmail.com \
    --to=raistlin.df@gmail.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=wei.liu2@citrix.com \
    --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.