All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: NUMA-aware VM placement in Xen
Date: Fri, 24 Feb 2012 11:12:03 +0100	[thread overview]
Message-ID: <1330078323.5034.73.camel@Abyss> (raw)


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

Hi guys,

As some of you know I'm working on putting some kind of NUMA-aware
placement of the various VMs within Xen. This means I'm investigating
deeply how memory allocation works, which isn't an easy task for me (I
started completely from scratch), so forgive me if I say something
wrong! :-P

The status is I'm dealing for a while with a "design issue" I'd be very
glad to discuss with someone, as I'm not sure which path to go for...

To keep it short, what I need is a place --ideally during VM creation--
where I can check how much memory a VM wants against how much memory is
available in the various NUMA-nodes, and use this as the basis of my
decision. The question is, where is this place?

I traced memory related calls (e.g., for HVMs) from libxl__build_hvm to
xc_hvm_build_target_mem to setup_guest to xc_domain_populate_physmap and
alloc_domheap_pages. The last twos have been my target for a while, but
I'm not so sure they would be the right choice, mainly because both of
them are called for allocating _only_part_ of the VM's memory, i.e.,
some extents of it at each call (am I right?).

Basically, given alloc_domheap_pages uses d->node_affinity for deciding
from which node(s) to actually take memory from, I was planning to
either use the same mask or build a new one with similar purposes, the
problem being _where_ to populate it with the proper nodes.
I'm now looking at xc_domain_setmaxmem-->do_domctl(XEN_DOMCTL_max_mem),
although I think it's too early, and I'd end up guessing wrt a lot of
aspects... But considering xm/xend was doing the same even earlier (at
least I think)...

Sorry fro writing so much... Any help/ideas you feel comfortable with
sharing would be very appreciated! :-)

Thanks a lot and regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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:[~2012-02-24 10:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-24 10:12 Dario Faggioli [this message]
2012-02-24 10:16 ` NUMA-aware VM placement in Xen George Dunlap
2012-02-24 10:50   ` Dario Faggioli
2012-02-24 14:36     ` George Dunlap

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=1330078323.5034.73.camel@Abyss \
    --to=raistlin@linux.it \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xensource.com \
    /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.