[PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag

[PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag

[Roger Pau Monne]

Check if hosts have SMT based on the number of threads per core. A
value of threads per core different than 0 implies SMT support.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 sg-run-job     |  1 +
 ts-examine-cpu | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100755 ts-examine-cpu

diff --git a/sg-run-job b/sg-run-job
index 97011843..aa7953ac 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -679,6 +679,7 @@ proc examine-host-examine {install} {
     if {$ok} {
 	run-ts -.  =           ts-examine-serial-post + host
 	run-ts .   =           ts-examine-iommu       + host
+	run-ts .   =           ts-examine-cpu         + host
 	run-ts .   =           ts-examine-logs-save   + host
 	run-ts .   =           ts-examine-hostprops-save
     }
diff --git a/ts-examine-cpu b/ts-examine-cpu
new file mode 100755
index 00000000..98ffab59
--- /dev/null
+++ b/ts-examine-cpu
@@ -0,0 +1,32 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2020 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);
+BEGIN { unshift @INC, qw(.); }
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+our $info = target_cmd_output_root($ho, 'xl info', 10);
+our $threads = $info =~ s/^threads_per_core\s*:.*\s//;
+
+logm("$ho->{Ident} threads per core: $threads");
+hostflag_putative_record($ho, "smt", !!$threads);
-- 
2.26.0

[PATCH OSSTEST 2/2] make-flight: add a core scheduling job

[Roger Pau Monne]

Run a simple core scheduling tests on a host that has SMT support.
This is only enabled for Xen >= 4.13.

The runvar difference is:

+test-amd64-coresched-amd64-xl all_host_di_version 2020-02-10
+test-amd64-coresched-i386-xl  all_host_di_version 2020-02-10
+test-amd64-coresched-amd64-xl all_host_suite      stretch
+test-amd64-coresched-i386-xl  all_host_suite      stretch
+test-amd64-coresched-amd64-xl all_hostflags       arch-amd64,arch-xen-amd64,suite-stretch,purpose-test,smt
+test-amd64-coresched-i386-xl  all_hostflags       arch-i386,arch-xen-amd64,suite-stretch,purpose-test,smt
+test-amd64-coresched-amd64-xl arch                amd64
+test-amd64-coresched-i386-xl  arch                i386
+test-amd64-coresched-amd64-xl buildjob            build-amd64
+test-amd64-coresched-i386-xl  buildjob            build-i386
+test-amd64-coresched-amd64-xl debian_arch         amd64
+test-amd64-coresched-i386-xl  debian_arch         i386
+test-amd64-coresched-amd64-xl debian_kernkind     pvops
+test-amd64-coresched-i386-xl  debian_kernkind     pvops
+test-amd64-coresched-amd64-xl debian_suite        stretch
+test-amd64-coresched-i386-xl  debian_suite        stretch
+test-amd64-coresched-amd64-xl kernbuildjob        build-amd64-pvops
+test-amd64-coresched-i386-xl  kernbuildjob        build-i386-pvops
+test-amd64-coresched-amd64-xl kernkind            pvops
+test-amd64-coresched-i386-xl  kernkind            pvops
+test-amd64-coresched-amd64-xl toolstack           xl
+test-amd64-coresched-i386-xl  toolstack           xl
+test-amd64-coresched-amd64-xl xen_boot_append     sched-gran=core
+test-amd64-coresched-i386-xl  xen_boot_append     sched-gran=core
+test-amd64-coresched-amd64-xl xenbuildjob         build-amd64
+test-amd64-coresched-i386-xl  xenbuildjob         build-amd64

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 make-flight | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/make-flight b/make-flight
index 2f445d95..e656125e 100755
--- a/make-flight
+++ b/make-flight
@@ -763,6 +763,17 @@ test_matrix_do_one () {
   *)                test_dom0pvh=n ;;
   esac
 
+  # core scheduling tests for versions >= 4.13 only
+  case "$xenbranch" in
+  xen-3.*-testing)  test_coresched=n ;;
+  xen-4.?-testing)  test_coresched=n ;;
+  xen-4.10-testing) test_coresched=n ;;
+  xen-4.11-testing) test_coresched=n ;;
+  xen-4.12-testing) test_coresched=n ;;
+  *)                test_coresched=y ;;
+  esac
+
+
   # xend PV guest test on x86 only
   if [ x$test_xend = xy -a \( $dom0arch = "i386" -o $dom0arch = "amd64" \) ]; then
     job_create_test test-$xenarch$kern-$dom0arch-pv test-debian xend \
@@ -894,6 +905,15 @@ test_matrix_do_one () {
 
   fi
 
+  # Core-scheduling tests are x86 only
+  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
+    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
+                    test-debian xl $xenarch $dom0arch $debian_runvars \
+                    all_hostflags=$most_hostflags,smt \
+                    xen_boot_append='sched-gran=core'
+
+  fi
+
   #do_passthrough_tests
 
   do_pygrub_tests
-- 
2.26.0

Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job

[Ian Jackson]

Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core scheduling job"):
> Run a simple core scheduling tests on a host that has SMT support.
> This is only enabled for Xen >= 4.13.
...
> +  # Core-scheduling tests are x86 only
> +  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
> +    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
> +                    test-debian xl $xenarch $dom0arch $debian_runvars \
> +                    all_hostflags=$most_hostflags,smt \
> +                    xen_boot_append='sched-gran=core'
> +
> +  fi

This seems fine as far as it goes, but all it does is check that
things still work if sched-gran=core is passed.  I'm not sure whether
anything more sophisticated is needed, and in any case this is a step
in the right direction, so:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(subject to my comment on 1/ about the flag name.)

Ian.

Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job

[Dario Faggioli]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core
> scheduling job"):
> > Run a simple core scheduling tests on a host that has SMT support.
> > This is only enabled for Xen >= 4.13.
> ...
> > +  # Core-scheduling tests are x86 only
> > +  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
> > +    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
> > +                    test-debian xl $xenarch $dom0arch
> > $debian_runvars \
> > +                    all_hostflags=$most_hostflags,smt \
> > +                    xen_boot_append='sched-gran=core'
> > +
> > +  fi
> 
> This seems fine as far as it goes, but all it does is check that
> things still work if sched-gran=core is passed. 
>
Yep, and that's enough for enabling and starting using ore-scheduling.
So, doing like this, core-scheduling should get the same amount and
kind of testing that scheduling in general gets.

>  I'm not sure whether
> anything more sophisticated is needed, and in any case this is a step
> in the right direction, so:
> 
Indeed.

One question, as my OSSTest-fu is a bit rusty... does this create
"sched-gran=core" tests for all the schedulers? Or just one of them for
th default scheduler?

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


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

Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job

[Roger Pau Monné]

On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH OSSTEST 2/2] make-flight: add a core
> > scheduling job"):
> > > Run a simple core scheduling tests on a host that has SMT support.
> > > This is only enabled for Xen >= 4.13.
> > ...
> > > +  # Core-scheduling tests are x86 only
> > > +  if [ x$test_coresched = xy -a $xenarch = amd64 ]; then
> > > +    job_create_test test-$xenarch$kern-coresched-$dom0arch-xl \
> > > +                    test-debian xl $xenarch $dom0arch
> > > $debian_runvars \
> > > +                    all_hostflags=$most_hostflags,smt \
> > > +                    xen_boot_append='sched-gran=core'
> > > +
> > > +  fi
> > 
> > This seems fine as far as it goes, but all it does is check that
> > things still work if sched-gran=core is passed. 
> >
> Yep, and that's enough for enabling and starting using ore-scheduling.
> So, doing like this, core-scheduling should get the same amount and
> kind of testing that scheduling in general gets.

Well, we run a lot more tests without 'sched-gran=core', but I don't
think it's feasible to duplicate the matrix to run all tests with and
without core-scheduling.

> >  I'm not sure whether
> > anything more sophisticated is needed, and in any case this is a step
> > in the right direction, so:
> > 
> Indeed.
> 
> One question, as my OSSTest-fu is a bit rusty... does this create
> "sched-gran=core" tests for all the schedulers? Or just one of them for
> th default scheduler?

Just for the default scheduler ATM, we can expand this if required.
The test also is very simple, as it just creates a Debian PV guest
and does some basic life cycle operations, it's exactly like the job
below but with 'sched-gran=core':

http://logs.test-lab.xenproject.org/osstest/logs/149667/test-amd64-amd64-xl/info.html

Roger.

Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job

[Dario Faggioli]

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]

On Thu, 2020-04-16 at 18:36 +0200, Roger Pau Monné wrote:
> On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> > On Wed, 2020-04-15 at 14:06 +0100, Ian Jackson wrote:
> > > 
> > > This seems fine as far as it goes, but all it does is check that
> > > things still work if sched-gran=core is passed. 
> > > 
> > Yep, and that's enough for enabling and starting using ore-
> > scheduling.
> > So, doing like this, core-scheduling should get the same amount and
> > kind of testing that scheduling in general gets.
> 
> Well, we run a lot more tests without 'sched-gran=core', but I don't
> think it's feasible to duplicate the matrix to run all tests with and
> without core-scheduling.
> 
Sure, but again, that's the kind of scheduling testing that we do.
E.g., right now that Credit2 is the default scheduler, we still test
the other schedulers, exactly with "just" a job like this (AFAICR, at
least).

It indeed would be good to have something more specific, not only for
core-scheduling, but for scheduling in general. But it's not there
right now... That was the point. :-)

Of course the default setup (which, currently, has "sched-gran=cpu") is
stressed much more, because all the other jobs also use it, but indeed
it does not appear sensible to replicate the matrix for each job that
we have with a non-default configuration.

> > One question, as my OSSTest-fu is a bit rusty... does this create
> > "sched-gran=core" tests for all the schedulers? Or just one of them
> > for
> > th default scheduler?
> 
> Just for the default scheduler ATM, we can expand this if required.
>
Ok, sure. Maybe it would make sense to add just another one for Credit,
sooner rather than later, as I guess there may be people wanting to
continue use Credit, but they may want to try it with core-scheduling.

Of course, this can be done on top of this patch... I was just thinking
out loud here. :-)

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)


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

Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job

[Ian Jackson]

Dario Faggioli writes ("Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job"):
> Ok, sure. Maybe it would make sense to add just another one for Credit,
> sooner rather than later, as I guess there may be people wanting to
> continue use Credit, but they may want to try it with core-scheduling.

Maybe in return we could delete the rtds test which has been marked
nonblocking forever and which no-one seems to be fixing ? :-)

Patches welcome...

Ian.

Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job

[Ian Jackson]

Roger Pau Monne writes ("Re: [PATCH OSSTEST 2/2] make-flight: add a core scheduling job"):
> On Thu, Apr 16, 2020 at 06:28:33PM +0200, Dario Faggioli wrote:
> > Yep, and that's enough for enabling and starting using ore-scheduling.
> > So, doing like this, core-scheduling should get the same amount and
> > kind of testing that scheduling in general gets.
> 
> Well, we run a lot more tests without 'sched-gran=core', but I don't
> think it's feasible to duplicate the matrix to run all tests with and
> without core-scheduling.

Yes, I agree with Roger.

> > One question, as my OSSTest-fu is a bit rusty... does this create
> > "sched-gran=core" tests for all the schedulers? Or just one of them for
> > th default scheduler?
> 
> Just for the default scheduler ATM, we can expand this if required.
> The test also is very simple, as it just creates a Debian PV guest
> and does some basic life cycle operations, it's exactly like the job
> below but with 'sched-gran=core':
> 
> http://logs.test-lab.xenproject.org/osstest/logs/149667/test-amd64-amd64-xl/info.html

Right.

Thanks,
Ian.

[PATCH OSSTEST v2 1/2] exanime: test for SMT and add a host flag

[Roger Pau Monne]

Check if hosts have SMT based on the number of threads per core. A
value of threads per core greater than 1 implies SMT support.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Fix regex and set SMT if number of threads per core is > 1.
---
 sg-run-job     |  1 +
 ts-examine-cpu | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100755 ts-examine-cpu

diff --git a/sg-run-job b/sg-run-job
index 97011843..aa7953ac 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -679,6 +679,7 @@ proc examine-host-examine {install} {
     if {$ok} {
 	run-ts -.  =           ts-examine-serial-post + host
 	run-ts .   =           ts-examine-iommu       + host
+	run-ts .   =           ts-examine-cpu         + host
 	run-ts .   =           ts-examine-logs-save   + host
 	run-ts .   =           ts-examine-hostprops-save
     }
diff --git a/ts-examine-cpu b/ts-examine-cpu
new file mode 100755
index 00000000..c30311ab
--- /dev/null
+++ b/ts-examine-cpu
@@ -0,0 +1,32 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2020 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);
+BEGIN { unshift @INC, qw(.); }
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+our $info = target_cmd_output_root($ho, 'xl info', 10);
+our $threads = $info =~ /^threads_per_core\s*:\s.*/m;
+
+logm("$ho->{Ident} threads per core: $threads");
+hostflag_putative_record($ho, "smt", $threads > 1);
-- 
2.26.0

Re: [PATCH OSSTEST v2 1/2] exanime: test for SMT and add a host flag

[Ian Jackson]

Roger Pau Monne writes ("[PATCH OSSTEST v2 1/2] exanime: test for SMT and add a host flag"):
> Check if hosts have SMT based on the number of threads per core. A
> value of threads per core greater than 1 implies SMT support.

I spotted the "0" in v1 but since you had clearly stated the same
thing in the commit message too I thought you knew what you were doing
:-).

Thanks,
Ian.

Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag

[Ian Jackson]

Roger Pau Monne writes ("[PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag"):
> Check if hosts have SMT based on the number of threads per core. A
> value of threads per core different than 0 implies SMT support.
...
> +logm("$ho->{Ident} threads per core: $threads");
> +hostflag_putative_record($ho, "smt", !!$threads);

This code LGTM but I wonder if it would be a good idea to start
namespacing these kind of hardware feature flags.  cpu-*, hardware-*,
feature-* maybe ?  Would you care to make a suggestion ?

Ian.

Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag

[Roger Pau Monné]

On Wed, Apr 15, 2020 at 02:04:35PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag"):
> > Check if hosts have SMT based on the number of threads per core. A
> > value of threads per core different than 0 implies SMT support.
> ...
> > +logm("$ho->{Ident} threads per core: $threads");
> > +hostflag_putative_record($ho, "smt", !!$threads);
> 
> This code LGTM but I wonder if it would be a good idea to start
> namespacing these kind of hardware feature flags.  cpu-*, hardware-*,
> feature-* maybe ?  Would you care to make a suggestion ?

cpu-smt seems fine if we plan to do similar namespacing with other
hardware features, I could see cpu-{smt,vmx,svm} and
devices-{iommu,sriov,ats} or some such for example.

If OTOH we don't want to be that fine grained I think
hw-{smt,iommu,vmx,...} would also be fine.

Not sure whether this has helped much. I guess my vote would be for
cpu-smt namespace.

Thanks, Roger.

Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag

[Ian Jackson]

Roger Pau Monne writes ("Re: [PATCH OSSTEST 1/2] exanime: test for SMT and add a host flag"):
> If OTOH we don't want to be that fine grained I think
> hw-{smt,iommu,vmx,...} would also be fine.
> 
> Not sure whether this has helped much. I guess my vote would be for
> cpu-smt namespace.

Let's go with hw-*.  That will avoid chopping logic over the precise
nature of hardware features, especially ones which have elements in
multiple components.

Thanks,
Ian.