Skip to contentSkip to conversation

Test case for cpupools

PATCH Superseded Dario Faggioli 4 participants 13 messages Dec 18, 2014 – Dec 19, 2014

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

cover Test case for cpupools

Just the fact that we are not doing anything to smoke test cpupools, while I think we should. :-)

This add something quite basic, but it's, IMO, already representative one typically does with cpupools. We can add more pCPU related tricks (removing, adding, etc), or we can add more domains and move them around more, of course. If anyone has any suggestion about operations that should really be part of Osstest's runs, let me know and I'll include them.

As it is right now, the test is super quick, to the point that I considered whether it wouldn't have been better to add some similar cpupool operations in one of the existing jobs. I ended up deciding for having a separate job, because this is, after all, a rather specific operation, and a different enough thing from basic VM lifecycle, so I think it deserves its own job.

Thanks and Regards, Dario

---

Dario Faggioli (2):
ts-cpupools: new test script
Testing cpupools: recipe for it and job definition

 make-flight |   11 +++++
 sg-run-job  |    6 +++
 ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 141 insertions(+)
 create mode 100755 ts-cpupools

--
<<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)

#1 lore raw

PATCH 1/2 ts-cpupools: new test script

for smoke testing cpupools a bit. It tries to partition a live host in two cpupools, trying out the following 3 schedulers for the new cpupool (one after the other):
credit, credit2 and RTDS.

It also tries to migrating a domain to the new cpupool and then back to Pool-0.

---
 ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 124 insertions(+)
 create mode 100755 ts-cpupools
ts-cpupools new file +124 -0
new file mode 100755
index 0000000..fe612e1
@@ -0,0 +1,124 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn)= @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debian';
+
+our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
+#our $ho= selecthost(@ARGV);
+
+our $default_cpupool= "Pool-0";
+our @schedulers= ("credit","credit2","rtds");
+our @cpulist;
+our $nr_cpus;
+
+sub check () {
+  my $out;
+
+  # Figure out the number of pCPUs of the host. We need to know
+  # that in order to decide with what pCPUs we want to create
+  # cpupools
+  my $xlinfo= target_cmd_output_root($ho, "xl info");
+  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
+  $nr_cpus= $1;
+  logm("Found $nr_cpus pCPUs");
+  die "Too few pCPUs to test cpupools: $nr_cpus" if $nr_cpus < 2;
+
+  # We want only 1 cpupool to exist
+  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
+  my $nr_cpupools= $cppinfo =~ tr/\n//;
+  logm("Found $nr_cpupools cpupools");
+  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
+  die "Non-default cpupool configuration detected" if $cppinfo =~ /^$default_cpupool\b/;
+
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+}
+
+# List of the odd pCPUs
+sub prep_cpulist () {
+  if (! defined @cpulist) {
+    foreach my $cpu (0..$nr_cpus) {
+      next unless $cpu % 2;
+      push @cpulist, $cpu;
+    }
+  }
+}
+
+sub prep ($) {
+  my ($sched)= @_;
+
+  # Remove the pCPUs from in $cpulist from the default cpupool
+  my $cpustr= "[";
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove $default_cpupool $cpu");
+    $cpustr.= "\"$cpu\", ";
+  }
+  $cpustr.= "]";
+
+  logm("Creating config file for cpupool-osstest-$sched with cpus=$cpustr");
+  target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-osstest-$sched");
+name = "cpupool-osstest-$sched"
+sched=\"$sched\"
+cpus=$cpustr
+END
+}
+
+check();
+prep_cpulist();
+foreach my $sched (@schedulers) {
+  my $out;
+
+  prep("$sched");
+
+  # For each cpupool:
+  #  * create it
+  #  * rename it
+  #  * move a domain in it
+  #  * move back a domain out of it
+  #  * add back the pcpus from it to the default pool
+  #  * destroy it
+  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-osstest-$sched");
+  target_cmd_output_root($ho, "xl cpupool-rename cpupool-osstest-$sched cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl vcpu-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
+    target_cmd_root($ho,"xl cpupool-cpu-add $default_cpupool $cpu");
+  }
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+}
+
Acked-by on v1 1/2
#2 lore raw

Re: [OSSTEST PATCH 1/2] ts-cpupools: new test script

Quoted 9 lines · Dario Faggioli

for smoke testing cpupools a bit. It tries to partition a live host in two cpupools, trying out the following 3 schedulers for the new cpupool (one after the other):
credit, credit2 and RTDS.

It also tries to migrating a domain to the new cpupool and then back to Pool-0.

Quoted 142 lines
---
  ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 124 insertions(+)

create mode 100755 ts-cpupools

ts-cpupools new file +124 -0
new file mode 100755
index 0000000..fe612e1
@@ -0,0 +1,124 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost,$gn)= @ARGV;
+$whhost ||= 'host';
+$gn ||= 'debian';
+
+our ($ho,$gho) = ts_get_host_guest($whhost,$gn);
+#our $ho= selecthost(@ARGV);
+
+our $default_cpupool= "Pool-0";
+our @schedulers= ("credit","credit2","rtds");
+our @cpulist;
+our $nr_cpus;
+
+sub check () {
+  my $out;
+
+  # Figure out the number of pCPUs of the host. We need to know
+  # that in order to decide with what pCPUs we want to create
+  # cpupools
+  my $xlinfo= target_cmd_output_root($ho, "xl info");
+  $xlinfo =~ /nr_cpus\s*:\s([0-9]*)/;
+  $nr_cpus= $1;
+  logm("Found $nr_cpus pCPUs");
+  die "Too few pCPUs to test cpupools: $nr_cpus" if $nr_cpus < 2;
+
+  # We want only 1 cpupool to exist
+  my $cppinfo= target_cmd_output_root($ho, "xl cpupool-list");
+  my $nr_cpupools= $cppinfo =~ tr/\n//;
+  logm("Found $nr_cpupools cpupools");
+  die "There already is more than one cpu pool!" if $nr_cpupools > 1;
+  die "Non-default cpupool configuration detected" if $cppinfo =~ /^$default_cpupool\b/;
+
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+}
+
+# List of the odd pCPUs
+sub prep_cpulist () {
+  if (! defined @cpulist) {
+    foreach my $cpu (0..$nr_cpus) {
+      next unless $cpu % 2;
+      push @cpulist, $cpu;
+    }
+  }
+}
+
+sub prep ($) {
+  my ($sched)= @_;
+
+  # Remove the pCPUs from in $cpulist from the default cpupool
+  my $cpustr= "[";
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove $default_cpupool $cpu");
+    $cpustr.= "\"$cpu\", ";
+  }
+  $cpustr.= "]";
+
+  logm("Creating config file for cpupool-osstest-$sched with cpus=$cpustr");
+  target_putfilecontents_stash($ho,100,<<"END","/etc/xen/cpupool-osstest-$sched");
+name = "cpupool-osstest-$sched"
+sched=\"$sched\"
+cpus=$cpustr
+END
+}
+
+check();
+prep_cpulist();
+foreach my $sched (@schedulers) {
+  my $out;
+
+  prep("$sched");
+
+  # For each cpupool:
+  #  * create it
+  #  * rename it
+  #  * move a domain in it
+  #  * move back a domain out of it
+  #  * add back the pcpus from it to the default pool
+  #  * destroy it
+  target_cmd_root($ho, "xl cpupool-create /etc/xen/cpupool-osstest-$sched");
+  target_cmd_output_root($ho, "xl cpupool-rename cpupool-osstest-$sched cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+  $out= target_cmd_output_root($ho, "xl vcpu-list"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-migrate $gho->{Name} Pool-0");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+
+  foreach my $cpu (@cpulist) {
+    target_cmd_root($ho,"xl cpupool-cpu-remove cpupool-test $cpu");
+    target_cmd_root($ho,"xl cpupool-cpu-add $default_cpupool $cpu");
+  }
+  $out= target_cmd_output_root($ho, "xl cpupool-list -c"); logm("$out");
+
+  target_cmd_root($ho, "xl cpupool-destroy cpupool-test");
+  $out= target_cmd_output_root($ho, "xl cpupool-list"); logm("$out");
+}
+

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#3 lore raw

PATCH 2/2 Testing cpupools: recipe for it and job definition

In reply to Dario Faggioli
---
 make-flight |   11 +++++++++++
 sg-run-job  |    6 ++++++
 2 files changed, 17 insertions(+)
make-flight +11 -0
index a91f256..ce02c89 100755
@@ -266,6 +266,16 @@ do_credit2_tests () {
             $debian_runvars all_hostflags=$most_hostflags
 }
 
+do_cpupools_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
+    return
+  fi
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
+       test-cpupools xl $xenarch $dom0arch                            \
+            $debian_runvars all_hostflags=$most_hostflags
+}
+
 do_passthrough_tests () {
   if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
     return
@@ -366,6 +376,7 @@ test_matrix_do_one () {
 
   do_sedf_tests
   do_credit2_tests
+  do_cpupools_tests
 
   if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
 
sg-run-job +6 -0
index 2cf810a..0250087 100755
@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
     test-guest debianhvm
 }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+    install-guest-debian
+    run-ts . = ts-cpupools
+}
+
 proc need-hosts/test-pair {} { return {src_host dst_host} }
 proc run-job/test-pair {} {
     run-ts . =              ts-debian-install      dst_host
#4 lore raw

Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition

Quoted 11 lines · Dario Faggioli
---
  make-flight |   11 +++++++++++
  sg-run-job  |    6 ++++++
  2 files changed, 17 insertions(+)
make-flight +0 -0
index a91f256..ce02c89 100755

make-flight do_credit2_tests () { · line 272

Quoted 7 lines
make-flight +4 -0
@@ -266,6 +266,16 @@ do_credit2_tests () {
              $debian_runvars all_hostflags=$most_hostflags
  }
 
+do_cpupools_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
+    return
+  fi

Why can't you test cpupools on x86_64?

Juergen

Quoted 41 lines
make-flight +7 -0
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
+       test-cpupools xl $xenarch $dom0arch                            \
+            $debian_runvars all_hostflags=$most_hostflags
+}
+
  do_passthrough_tests () {
    if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
      return
@@ -366,6 +376,7 @@ test_matrix_do_one () {
 
    do_sedf_tests
    do_credit2_tests
+  do_cpupools_tests
 
    if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
 
sg-run-job +6 -0
index 2cf810a..0250087 100755
@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
      test-guest debianhvm
  }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+    install-guest-debian
+    run-ts . = ts-cpupools
+}
+
  proc need-hosts/test-pair {} { return {src_host dst_host} }
  proc run-job/test-pair {} {
      run-ts . =              ts-debian-install      dst_host

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#5 lore raw

Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition

Quoted 15 lines · Juergen Gross
Quoted 14 lines · Dario Faggioli
---
 make-flight |   11 +++++++++++
 sg-run-job  |    6 ++++++
 2 files changed, 17 insertions(+)
make-flight +0 -0
index a91f256..ce02c89 100755
@@ -266,6 +266,16 @@ do_credit2_tests () {
             $debian_runvars all_hostflags=$most_hostflags
 }
 
Quoted 7 lines

make-flight do_credit2_tests () { · line 272

Quoted 4 lines
make-flight +4 -0
+do_cpupools_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
+    return
+  fi

Why can't you test cpupools on x86_64?

Don't worry. That's the name used for 64 bit (be it amd or intel) in OSSTest. :-)

Wei.

Quoted 44 lines

Juergen

Quoted 41 lines
make-flight +7 -0
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
+       test-cpupools xl $xenarch $dom0arch                            \
+            $debian_runvars all_hostflags=$most_hostflags
+}
+
 do_passthrough_tests () {
   if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
     return
@@ -366,6 +376,7 @@ test_matrix_do_one () {
 
   do_sedf_tests
   do_credit2_tests
+  do_cpupools_tests
 
   if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
 
sg-run-job +6 -0
index 2cf810a..0250087 100755
@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
     test-guest debianhvm
 }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+    install-guest-debian
+    run-ts . = ts-cpupools
+}
+
 proc need-hosts/test-pair {} { return {src_host dst_host} }
 proc run-job/test-pair {} {
     run-ts . =              ts-debian-install      dst_host

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#6 lore raw

Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition

Quoted 24 lines · Wei Liu
Quoted 15 lines · Juergen Gross
Quoted 14 lines · Dario Faggioli
---
  make-flight |   11 +++++++++++
  sg-run-job  |    6 ++++++
  2 files changed, 17 insertions(+)
make-flight +0 -0
index a91f256..ce02c89 100755
@@ -266,6 +266,16 @@ do_credit2_tests () {
              $debian_runvars all_hostflags=$most_hostflags
  }
 
Quoted 7 lines

make-flight do_credit2_tests () { · line 272

Quoted 4 lines
make-flight +4 -0
+do_cpupools_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
+    return
+  fi

Why can't you test cpupools on x86_64?

Quoted 2 lines

Don't worry. That's the name used for 64 bit (be it amd or intel) in OSSTest. :-)

Aargh. Some automatic filter in my brain translated this to arm64 :-)

So: Why can't you test cpupools on ARM?

Juergen

Quoted 48 lines

Wei.

Quoted 44 lines

Juergen

Quoted 41 lines
make-flight +7 -0
+
+  job_create_test test-$xenarch$kern-$dom0arch-xl-cpupools            \
+       test-cpupools xl $xenarch $dom0arch                            \
+            $debian_runvars all_hostflags=$most_hostflags
+}
+
  do_passthrough_tests () {
    if [ $xenarch != amd64 -o $dom0arch != amd64 -o "$kern" != "" ]; then
      return
@@ -366,6 +376,7 @@ test_matrix_do_one () {
 
    do_sedf_tests
    do_credit2_tests
+  do_cpupools_tests
 
    if [ $xenarch = amd64 -a $dom0arch = i386 ]; then
 
sg-run-job +6 -0
index 2cf810a..0250087 100755
@@ -272,6 +272,12 @@ proc run-job/test-debianhvm {} {
      test-guest debianhvm
  }
 
+proc need-hosts/test-cpupools {} { return host }
+proc run-job/test-cpupools {} {
+    install-guest-debian
+    run-ts . = ts-cpupools
+}
+
  proc need-hosts/test-pair {} { return {src_host dst_host} }
  proc run-job/test-pair {} {
      run-ts . =              ts-debian-install      dst_host

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#7 lore raw

Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition

Quoted 25 lines · Juergen Gross
Quoted 24 lines · Wei Liu
Quoted 22 lines · Juergen Gross
Quoted 11 lines · Dario Faggioli
---
  make-flight |   11 +++++++++++
  sg-run-job  |    6 ++++++
  2 files changed, 17 insertions(+)
make-flight +0 -0
index a91f256..ce02c89 100755

make-flight do_credit2_tests () { · line 272

Quoted 7 lines
make-flight +4 -0
@@ -266,6 +266,16 @@ do_credit2_tests () {
              $debian_runvars all_hostflags=$most_hostflags
  }
 
+do_cpupools_tests () {
+  if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then
+    return
+  fi

Why can't you test cpupools on x86_64?

Quoted 3 lines
Quoted 2 lines

Don't worry. That's the name used for 64 bit (be it amd or intel) in OSSTest. :-)

Exactly, it comes from the Debian arches names.

Quoted 2 lines

Aargh. Some automatic filter in my brain translated this to arm64 :-)

HeHe :-)

Quoted 2 lines

So: Why can't you test cpupools on ARM?

We certainly can. ARM testing via OSSTest is a still experimental, AFAIUI.

I don't even know if we have the hardware, yet, as I think the "rack" of ARM dev board IanC was working on will be setup in the new testing COLO, rather than in current OSSTest pool of hardware (someone correct me if I'm wrong).

However, that seems to be taken into account by the fact that, in make-flight, in test_matrix_do_one(), after only 2 jobs are created (the basic debian one and a libvirt one) we have this:

# No further arm tests at the moment
if [ $dom0arch = armhf ]; then
return
fi

So, yes, I guess I can get rid of such filters in my new function, so that, when ARM maintainers will disable the safety catch above, a job will actually be generated.

I'll give it a shot for v2.

Thanks and Regards,
Dario

Signature · 4 lines
<<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)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#8 lore raw

Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition

Quoted 6 lines · Dario Faggioli
Quoted 2 lines · Juergen Gross

So: Why can't you test cpupools on ARM?

We certainly can. ARM testing via OSSTest is a still experimental, AFAIUI.

arm32 testing is production in osstest.

Quoted 4 lines

I don't even know if we have the hardware, yet, as I think the "rack" of ARM dev board IanC was working on will be setup in the new testing COLO, rather than in current OSSTest pool of hardware (someone correct me if I'm wrong).

The new rack is to replace the existing h/w used in production, since that can't be shipped to the colo for various reasons.

Quoted 4 lines

However, that seems to be taken into account by the fact that, in make-flight, in test_matrix_do_one(), after only 2 jobs are created (the basic debian one and a libvirt one) we have this:

Quoted 8 lines

# No further arm tests at the moment
if [ $dom0arch = armhf ]; then
return
fi

So, yes, I guess I can get rid of such filters in my new function, so that, when ARM maintainers will disable the safety catch above, a job will actually be generated.

We should probably move some of the tests from below the cut to above already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific, so should be run on arm.

That's not your problem, but if you could add the new test above the cut that would be great. I'll sort out the other ones at some point.

Ian.

#9 lore raw

Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition

Quoted 10 lines · Ian Campbell
Quoted 6 lines · Dario Faggioli
Quoted 2 lines · Juergen Gross

So: Why can't you test cpupools on ARM?

We certainly can. ARM testing via OSSTest is a still experimental, AFAIUI.

arm32 testing is production in osstest.

Quoted 8 lines
Quoted 4 lines

I don't even know if we have the hardware, yet, as I think the "rack" of ARM dev board IanC was working on will be setup in the new testing COLO, rather than in current OSSTest pool of hardware (someone correct me if I'm wrong).

The new rack is to replace the existing h/w used in production, since that can't be shipped to the colo for various reasons.

Ok.

Quoted 9 lines
Quoted 9 lines

However, that seems to be taken into account by the fact that, in make-flight, in test_matrix_do_one(), after only 2 jobs are created (the basic debian one and a libvirt one) we have this:

# No further arm tests at the moment
if [ $dom0arch = armhf ]; then
return
fi

Quoted 8 lines
Quoted 3 lines

So, yes, I guess I can get rid of such filters in my new function, so that, when ARM maintainers will disable the safety catch above, a job will actually be generated.

We should probably move some of the tests from below the cut to above already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific, so should be run on arm.

I see. Great. :-)

Scheduler testing being below the cutoff was exactly what made me thinking that we only wanted basic ARM testing for now, given the limited HW resources, and to keep the "noise" low.

I'll certainly move this one below it.

Quoted 3 lines

That's not your problem, but if you could add the new test above the cut that would be great. I'll sort out the other ones at some point.

Sure I will.

Thanks and Regards,
Dario

Signature · 4 lines
<<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)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#10 lore raw

Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition

Quoted 17 lines · Dario Faggioli
Quoted 9 lines
Quoted 9 lines

However, that seems to be taken into account by the fact that, in make-flight, in test_matrix_do_one(), after only 2 jobs are created (the basic debian one and a libvirt one) we have this:

# No further arm tests at the moment
if [ $dom0arch = armhf ]; then
return
fi

Quoted 8 lines
Quoted 3 lines

So, yes, I guess I can get rid of such filters in my new function, so that, when ARM maintainers will disable the safety catch above, a job will actually be generated.

We should probably move some of the tests from below the cut to above already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific, so should be run on arm.

Quoted 5 lines

I see. Great. :-)

Scheduler testing being below the cutoff was exactly what made me thinking that we only wanted basic ARM testing for now, given the limited HW resources, and to keep the "noise" low

Actually if anything we are underutilising the ARM resources we have, they usually finish way in advance of all the x86 stuff.

Ian.

#11 lore raw
In reply to Dario Faggioli
Quoted 9 lines · Dario Faggioli

Just the fact that we are not doing anything to smoke test cpupools, while I think we should. :-)

This add something quite basic, but it's, IMO, already representative one typically does with cpupools. We can add more pCPU related tricks (removing, adding, etc), or we can add more domains and move them around more, of course. If anyone has any suggestion about operations that should really be part of Osstest's runs, let me know and I'll include them.

Quoted 6 lines

As it is right now, the test is super quick, to the point that I considered whether it wouldn't have been better to add some similar cpupool operations in one of the existing jobs. I ended up deciding for having a separate job, because this is, after all, a rather specific operation, and a different enough thing from basic VM lifecycle, so I think it deserves its own job.

And I forgot to say that I of course tested it, in standalone mode, like this:

 $ ./standalone run-job -h ultralisk test-amd64-amd64-xl-cpupools

Here's also the runvars for the new job (really nothing special):

 test-amd64-amd64-xl-cpupools              all_hostflags               arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test                             
 test-amd64-amd64-xl-cpupools              arch                        amd64                                                                           
 test-amd64-amd64-xl-cpupools              buildjob                    build-amd64                                                                     
 test-amd64-amd64-xl-cpupools              console                     hvc0                                                                            
 test-amd64-amd64-xl-cpupools              debian_arch                 amd64                                                                           
 test-amd64-amd64-xl-cpupools              debian_boot_timeout         40                                                                              
 test-amd64-amd64-xl-cpupools              debian_cfgpath              /etc/xen/debian.guest.osstest.cfg                                               
 test-amd64-amd64-xl-cpupools              debian_console              hvc0                                                                            
 test-amd64-amd64-xl-cpupools              debian_disk_lv              debian.guest.osstest-disk                                                       
 test-amd64-amd64-xl-cpupools              debian_domname              debian.guest.osstest                                                            
 test-amd64-amd64-xl-cpupools              debian_ether                5e:36:06:68:00:01                                                               
 test-amd64-amd64-xl-cpupools              debian_hostname             debian.guest.osstest                                                            
 test-amd64-amd64-xl-cpupools              debian_kernkind             pvops                                                                           
 test-amd64-amd64-xl-cpupools              debian_rootdev              xvda                                                                            
 test-amd64-amd64-xl-cpupools              debian_swap_lv              debian.guest.osstest-swap                                                       
 test-amd64-amd64-xl-cpupools              debian_tcpcheckport         22                                                                              
 test-amd64-amd64-xl-cpupools              debian_vg                   ultralisk                                                                       
 test-amd64-amd64-xl-cpupools              host                        ultralisk                                                                       
 test-amd64-amd64-xl-cpupools              kernbuildjob                build-amd64-pvops                                                               
 test-amd64-amd64-xl-cpupools              kernkind                    pvops                                                                           
 test-amd64-amd64-xl-cpupools              toolstack                   xl                                                                              
 test-amd64-amd64-xl-cpupools              xen_kernel_path             /boot/vmlinuz-3.18.0-rc4                                                        
 test-amd64-amd64-xl-cpupools              xen_kernel_ver              3.18.0-rc4                                                                      
 test-amd64-amd64-xl-cpupools              xenbuildjob                 build-amd64

Dario

Signature · 4 lines
<<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)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#12 lore raw
In reply to Dario Faggioli
Quoted 9 lines · Dario Faggioli

Just the fact that we are not doing anything to smoke test cpupools, while I think we should. :-)

This add something quite basic, but it's, IMO, already representative one typically does with cpupools. We can add more pCPU related tricks (removing, adding, etc), or we can add more domains and move them around more, of course. If anyone has any suggestion about operations that should really be part of Osstest's runs, let me know and I'll include them.

Quoted 7 lines

As it is right now, the test is super quick, to the point that I considered whether it wouldn't have been better to add some similar cpupool operations in one of the existing jobs. I ended up deciding for having a separate job, because this is, after all, a rather specific operation, and a different enough thing from basic VM lifecycle, so I think it deserves its own job.

Thanks and Regards, Dario

Thanks for doing this!

Juergen

Quoted 25 lines

---

Dario Faggioli (2):
ts-cpupools: new test script
Testing cpupools: recipe for it and job definition

  make-flight |   11 +++++
  sg-run-job  |    6 +++
  ts-cpupools |  124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  3 files changed, 141 insertions(+)

create mode 100755 ts-cpupools

--
<<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)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel