All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>,
	Dario Faggioli <dario.faggioli@ctirix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [OSSTEST PATCH 1/2] TestSupport.pm: allow creating vNUMA enabled HVM guest configs
Date: Fri, 2 Oct 2015 12:32:42 +0100	[thread overview]
Message-ID: <20151002113242.GA30122@zion.uk.xensource.com> (raw)
In-Reply-To: <20151001231731.15271.87986.stgit@Solace.station>

On Fri, Oct 02, 2015 at 01:17:31AM +0200, Dario Faggioli wrote:
> This is done by introducing a new guest runvar, called
> 'vnodes', holding, if defined, the number of vNUMA nodes
> the guest should have.
> 
> >From that, and basing on the other characteristics of the
> guest (namely, amount of RAM and number of vcpus), we build
> a vNUMA topology that makes sense.
> 
> For now, we just evenly (well, as evenly as we can) split
> resouces between vNUMA nodes. Also, still for now, we
> always set things in such a way that all vNUMA nodes are
> allocated on physical NUMA node 0. This way, we don't
> have to introduce logic to make sure that the test runs
> on an actual NUMA host.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@ctirix.com>
> ---
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
>  Osstest/TestSupport.pm |   29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index 2b67e32..bf8bd56 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -1709,6 +1709,34 @@ sub prepareguest_part_xencfg ($$$$$) {
>      my $vifmodel= $vif ? "model=$vif," : '';
>      my $xoptcfg= $xopts->{ExtraConfig};
>      $xoptcfg='' unless defined $xoptcfg;
> +
> +    my $vnumacfg= '';
> +    my $vnuma_nodes= guest_var($gho, 'vnodes', $xopts->{DefVnodes} || 1);
> +    if ($vnuma_nodes > 1 && $vcpus >= $vnuma_nodes) {
> +        my @vnuma_mem;
> +        my @vnuma_pnode;
> +        my @vnuma_vcpus;
> +        my @vnuma;
> +
> +        my $m= int($ram_mb / $vnuma_nodes);
> +        @vnuma_mem = map { $_ < $vnuma_nodes ? $m :
> +            ($ram_mb - ($vnuma_nodes-1) * $m) } (1 .. $vnuma_nodes);
> +
> +        my $v= int($vcpus / $vnuma_nodes);
> +        @vnuma_vcpus= map { $_ == 0 ? "0-" . ($v-1) :
> +            $_ == $vnuma_nodes-1 ? ($_ * $v) . "-" . ($vcpus-1) :
> +            ($_ * $v) . "-" . (($_+1) * $v - 1) } (0 .. $vnuma_nodes-1);
> +
> +        # Let's put all vnodes on pnode 0, as we don't even know (for now)
> +        # whether or not the host has more NUMA nodes than that!
> +        @vnuma_pnode = (0) x $vnuma_nodes;
> +

The thing I worry about putting everything in node 0 is that if we
somehow has hardware that has several nodes but each node has relative
small amount of ram it would cause this test case to fail.

In the current arrangement, HVM guest gets 5G of ram if OSSTest
determines the host has enough (2x5G + slack) ram for it.  So vnuma test
case will fail on a box with 4 nodes but has 16G of ram. Is such
hardware configuration not very likely to exist?

Wei.

> +        @vnuma = map { $_ == -1 ? '[' : $_ == $vnuma_nodes ? ']' :
> +            "[\"pnode=$vnuma_pnode[$_]\",\"size=$vnuma_mem[$_]\",\"vcpus=$vnuma_vcpus[$_]\" ]," }
> +            (-1 .. $vnuma_nodes);
> +        $vnumacfg= "vnuma = @vnuma";
> +    }
> +
>      my $xencfg= <<END;
>  name        = '$gho->{Name}'
>  memory = ${ram_mb}
> @@ -1719,6 +1747,7 @@ on_reboot   = '$onreboot'
>  on_crash    = '$oncrash'
>  #
>  vcpus = $vcpus
> +$vnumacfg
>  #
>  $cfgrest
>  #

  reply	other threads:[~2015-10-02 11:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01 23:17 [OSSTEST PATCH 0/2] Testcase for HVM vNUMA Dario Faggioli
2015-10-01 23:17 ` [OSSTEST PATCH 1/2] TestSupport.pm: allow creating vNUMA enabled HVM guest configs Dario Faggioli
2015-10-02 11:32   ` Wei Liu [this message]
2015-10-02 12:02     ` Dario Faggioli
2015-10-02 12:18       ` Wei Liu
2015-10-02 12:30         ` Dario Faggioli
2015-10-02 12:21       ` Wei Liu
2015-10-02 12:32         ` Dario Faggioli
2015-10-01 23:17 ` [OSSTEST PATCH 2/2] make-flight: create the vNUMA HVM test job Dario Faggioli
2015-10-05 16:34   ` Ian Jackson
2015-10-05 16:41     ` Wei Liu
2015-10-06  8:23       ` Ian Campbell
2015-10-06  8:33         ` Dario Faggioli
2015-10-06  9:03           ` Ian Campbell
2015-10-06  9:13             ` Dario Faggioli
2015-10-06  9:05           ` Wei Liu
2015-10-06  9:18             ` Ian Campbell
2015-10-09 14:42   ` Ian Campbell
2015-10-02  9:33 ` [OSSTEST PATCH 0/2] Testcase for HVM vNUMA Dario Faggioli
2015-10-02 10:15 ` Dario Faggioli
2015-10-02 11:40   ` 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=20151002113242.GA30122@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=dario.faggioli@ctirix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --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.