From: Andre Przywara <andre.przywara@amd.com>
To: Dulloor <dulloor@gmail.com>, "Cui, Dexuan" <dexuan.cui@intel.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: NUMA guest: best-fit-nodes algorithm (was Re: [PATCH 00/11] PV NUMA Guests)
Date: Fri, 23 Apr 2010 14:45:58 +0200 [thread overview]
Message-ID: <4BD19686.1050602@amd.com> (raw)
Dulloor wrote:
> Cui, Dexuan <dexuan.cui@intel.com> wrote:
>> xc_select_best_fit_nodes() decides the "min-set" of host nodes that
>> will be used for the guest. It only considers the current memory
>> usage of the system. Maybe we should also condider the cpu load? And
>> the number of the nodes must be 2^^n? And how to handle the case
>> #vcpu is < #vnode?
>> And looks your patches only consider the guest's memory requirement
>> -- guest's vcpu requirement is neglected? e.g., a guest may not need
>> a very large amount of memory while it needs many vcpus.
>> xc_select_best_fit_nodes() should consider this when
>> determining the number of vnode.
> I agree with you. I was planning to consider vcpu load as the next
> step. Also, I am looking for a good heuristic. I looked at the
> nodeload heuristic (currently in xen), but found it too naive.
> But, if you/Andre think it is a good heuristic, I will add the
> support. Actually, I think in future we should do away with strict
> vcpu-affinities and rely more on a scheduler with necessary NUMA
> support to complement our placement strategies.
>
> As of now, we don't SPLIT, if #vcpu < #vnode. We use STRIPING in that
> case.
Determing the current load of a node is quite a hard thing to do
currently in Xen. If guests are pinned to nodes (which I'd consider
necessary with the current credit scheduler), then using this affinity
is a good heuristic to find good nodes, at least the best I can think
of. So until we have a NUMA aware scheduler, we should go with this
solution. Of course it only measures the theoretical load of a node and
doesn't distinguish between idle and loaded guests. One would need
something like a permanently running xm top to gather statistics about
the guest's load, but that is something for a future patch.
(Or is there a guest load metric already measured in Xen?)
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12
next reply other threads:[~2010-04-23 12:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-23 12:45 Andre Przywara [this message]
2010-04-24 6:51 ` NUMA guest: best-fit-nodes algorithm (was Re: [PATCH 00/11] PV NUMA Guests) Dulloor
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=4BD19686.1050602@amd.com \
--to=andre.przywara@amd.com \
--cc=dexuan.cui@intel.com \
--cc=dulloor@gmail.com \
--cc=jun.nakajima@intel.com \
--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.