All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] Add gnu testsuite execution for OEQA
@ 2019-07-06 11:39 Nathan Rossi
  2019-07-06 12:52 ` Richard Purdie
  2019-07-09 11:16 ` Burton, Ross
  0 siblings, 2 replies; 15+ messages in thread
From: Nathan Rossi @ 2019-07-06 11:39 UTC (permalink / raw)
  To: openembedded-core

This patch is an RFC for adding support to execute the gnu test suites for
binutils, gcc and glibc. With the intention for enabling automated test running
of these test suites within the OEQA framework such that they can be executed by
the Yocto Autobuilder.

Please note that this patch is not a complete implementation and needs
additional work as well as changes based on comments and feedback from this RFC.

The test suites covered need significant resources or build artifacts such
that running them on the target is undesirable which rules out the use of ptest.
Because of this the test suites can be run on the build host and if necessary
call out to the target.

The following implementation creates a number of recipes that are used to
build/execute the test suites for the different components. The reason for
creating separate recipes is primarily due to dependencies and the need for
components in the sysroot. For example binutils has tests that use the C
compiler however binutils is a dependency for the C compiler and thus would
cause a dependency loop. The issue with sysroots occurs with dependence on
`*-initial` recipes and the test suites needing the non-initial version.

Some issues with splitting the recipes:
 - Rebuilds the recipe
   - Like gcc-cross-testsuite in this patch, could use a stashed builddir
 - Source is duplicated
   - gcc gets around this with shared source
 - Requires having the recipe files and maintaining them
   - Multiple versions of recipes
   - Multiple variants of recipes (-cross, -crosssdk, -native if desired)

Target execution is another issue with the test suites. Note that binutils
however does not require any target execution. In this patch both
qemu-linux-user and ssh target execution solutions are provided. For the
purposes of OE, qemu-linux-user may suffice as it has great success at executing
gcc and gcc-runtime tests with acceptable success at executing the glibc tests.

The glibc test suite can be problematic to execute for a few reasons:
 - Requires access to the exact same filesystem as the build host
   - On physical targets and QEMU this requires NFS mounts
 - Relies on exact syscall behaviour
   - Causes some issues where there are differences between qemu-linux-user and
     the target architectures kernel
 - Can consume significant resources (e.g. OOM, or worse trigger bugs/panics in
   kernel drivers)
 - Slow to execute
   - With QEMU system emulation it can take many hours
   - With some physical target architectures it can take days (e.g. microblaze)

The significantly increased execution speed of qemu-linux-user vs qemu system
with glibc, and the ability for qemu-linux-user to be executed in parallel with
the gcc test suite makes it a strong solution for continuous integration
testing.

The following table shows results for the major test suite components running
with qemu-linux-user execution. The numbers represent 'failed tests'/'total
tests'. The machines used to run the tests are the `qemu*` machine for the
associated architecture, not all qemu machines available in oe-core were tested.
It is important to note that these results are only indicative of
qemu-linux-user behaviour and that there are a number of test failures that are
due to issues not specific to qemu-linux-user.

        | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847

This patch also introduces some OEQA test cases which cover running the test
suites. However in this specific patch it does not include any implementation
for the automated setup of qemu system emulation testing with runqemu and NFS
mounting for glibc tests. Also not included in these test cases is any known
test failure filtering.

I would also be interested in the opinion with regards to whether these test
suites should be executed as part of the existing Yocto Autobuilder instance.
---
 meta/lib/oeqa/selftest/cases/toolchain.py          |  24 +++++
 meta/recipes-core/glibc/glibc-testsuite_2.29.bb    | 120 +++++++++++++++++++++
 .../binutils/binutils-cross-testsuite_2.32.bb      |  25 +++++
 meta/recipes-devtools/gcc/gcc-common.inc           |   3 +-
 .../gcc/gcc-cross-testsuite_9.1.bb                 |  37 +++++++
 .../gcc/gcc-runtime-testsuite_9.1.bb               |  37 +++++++
 meta/recipes-devtools/gcc/gcc-testsuite.inc        |  65 +++++++++++
 7 files changed, 310 insertions(+), 1 deletion(-)
 create mode 100644 meta/lib/oeqa/selftest/cases/toolchain.py
 create mode 100644 meta/recipes-core/glibc/glibc-testsuite_2.29.bb
 create mode 100644 meta/recipes-devtools/binutils/binutils-cross-testsuite_2.32.bb
 create mode 100644 meta/recipes-devtools/gcc/gcc-cross-testsuite_9.1.bb
 create mode 100644 meta/recipes-devtools/gcc/gcc-runtime-testsuite_9.1.bb
 create mode 100644 meta/recipes-devtools/gcc/gcc-testsuite.inc

diff --git a/meta/lib/oeqa/selftest/cases/toolchain.py b/meta/lib/oeqa/selftest/cases/toolchain.py
new file mode 100644
index 0000000000..723bded98f
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/toolchain.py
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: MIT
+import os
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake, get_bb_var
+
+class OEToolchainSelfTest(OESelftestTestCase):
+    """
+    Test cases for OE's toolchain: binutils, gcc and glibc
+    """
+
+    def test_binutils_cross(self):
+        cross_pn = "binutils-cross-testsuite-{0}".format(get_bb_var("TUNE_ARCH"))
+        bitbake("{0} -c check".format(cross_pn))
+
+    def test_gcc_cross(self):
+        cross_pn = "gcc-cross-testsuite-{0}".format(get_bb_var("TUNE_ARCH"))
+        bitbake("{0} -c check".format(cross_pn))
+
+    def test_gcc_runtime(self):
+        bitbake("gcc-runtime-testsuite -c check")
+
+    def test_glibc(self):
+        bitbake("glibc-testsuite -c check")
+
diff --git a/meta/recipes-core/glibc/glibc-testsuite_2.29.bb b/meta/recipes-core/glibc/glibc-testsuite_2.29.bb
new file mode 100644
index 0000000000..bab5eb834a
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc-testsuite_2.29.bb
@@ -0,0 +1,120 @@
+require glibc_${PV}.bb
+
+# handle PN differences
+FILESEXTRAPATHS_prepend := "${THISDIR}/glibc:"
+
+# strip provides
+PROVIDES = ""
+# setup depends
+INHIBIT_DEFAULT_DEPS = ""
+
+DEPENDS += "glibc-locale libgcc gcc-runtime"
+
+# remove the initial depends
+DEPENDS_remove = "libgcc-initial"
+DEPENDS_remove = "linux-libc-headers"
+DEPENDS_remove = "virtual/${TARGET_PREFIX}libc-initial"
+DEPENDS_remove = "virtual/${TARGET_PREFIX}gcc-initial"
+
+inherit qemu
+
+DEPENDS += "qemu-native"
+
+# Add CFLAGS for GCC warnings that are new
+CFLAGS_append = " -Wno-error=alloc-size-larger-than="
+
+python dummy_test_wrapper_content() {
+    import sys
+    import os
+    import subprocess
+
+    args = sys.argv[1:]
+
+    if args[0] == "env":
+        args.pop(0)
+        while "=" in args[0]:
+            env = args.pop(0)
+            qemuargs.append("-E")
+            qemuargs.append(env)
+    if args[0] == "cp":
+        # ignore copies, the filesystem is the same
+        sys.exit(0)
+
+    r = subprocess.run(qemuargs + args)
+    sys.exit(r.returncode)
+}
+
+generate_test_wrapper_user[dirs] += "${WORKDIR}"
+python generate_test_wrapper_user() {
+    qemu_binary = qemu_target_binary(d)
+    qemu_binary = bb.utils.which(d.getVar("PATH"), qemu_binary)
+
+    if qemu_binary is None:
+        bb.fatal("Missing target qemu linux-user binary")
+
+    args = [qemu_binary]
+    args += (d.getVar("QEMU_OPTIONS") or "").split()
+    args += ["-L", d.getVar("RECIPE_SYSROOT")]
+    #args += ["-E", "LD_DEBUG=all"]
+    args += ["-E", "LD_LIBRARY_PATH=%s" % ":".join(["/usr/lib", "/lib"])]
+
+    formattedargs = " ".join("\"{0}\"".format(i) if (" " in i) else i for i in args)
+    testwrapper = os.path.join(d.getVar("WORKDIR"), "check-test-wrapper")
+    with open(testwrapper, "w") as f:
+        f.write("#!/usr/bin/env python3\n")
+        f.write("qemuargs = [\n")
+        for i in args:
+            if "\"" in i:
+                i = i.replace("\"", "\\\"")
+            f.write("    \"{0}\",\n".format(i))
+        f.write("    ]\n")
+
+        for i in d.getVar("dummy_test_wrapper_content").splitlines():
+            f.write("%s\n" % i[4:])
+    os.chmod(testwrapper, 0o755)
+}
+
+python dummy_test_wrapper_content_ssh() {
+    import sys
+    import os
+    import subprocess
+
+    args = ["ssh", "-p", port, "-o", "UserKnownHostsFile=/dev/null", "-o", "StrictHostKeyChecking=no", "{0}@{1}".format(user, host), "sh", "-c"]
+
+    command = ""
+    #command += "export TIMEOUTFACTOR=10000; "
+    command += " ".join(["'%s'" % i.replace("'", r"'\''") for i in ["cd", os.getcwd()]]) + "; "
+    command += " ".join(["'%s'" % i.replace("'", r"'\''") for i in sys.argv[1:]])
+    args.append("\"%s\"" % command)
+
+    r = subprocess.run(args)
+    sys.exit(r.returncode)
+}
+
+BUILD_TEST_HOST ??= "localhost"
+BUILD_TEST_HOST_USER ??= "root"
+BUILD_TEST_HOST_PORT ??= "2222"
+
+generate_test_wrapper_ssh[dirs] += "${WORKDIR}"
+generate_test_wrapper_ssh[vardeps] += "dummy_test_wrapper_content_ssh"
+python generate_test_wrapper_ssh() {
+    testwrapper = os.path.join(d.getVar("WORKDIR"), "check-test-wrapper")
+    with open(testwrapper, "w") as f:
+        f.write("%s\n" % "#!/usr/bin/env python3")
+        f.write("host = \"{0}\"\n".format(d.getVar("BUILD_TEST_HOST")))
+        f.write("user = \"{0}\"\n".format(d.getVar("BUILD_TEST_HOST_USER")))
+        f.write("port = \"{0}\"\n".format(d.getVar("BUILD_TEST_HOST_PORT")))
+        for i in d.getVar("dummy_test_wrapper_content_ssh").splitlines():
+            f.write("%s\n" % i[4:])
+    os.chmod(testwrapper, 0o755)
+}
+
+do_check[dirs] += "${B}"
+do_check[nostamp] = "1"
+do_check[prefuncs] += "generate_test_wrapper_user"
+addtask do_check after do_compile
+do_check () {
+    #oe_runmake test-wrapper='${WORKDIR}/check-test-wrapper' PARALLELMFLAGS="-j1" check
+    oe_runmake test-wrapper='${WORKDIR}/check-test-wrapper' check
+}
+
diff --git a/meta/recipes-devtools/binutils/binutils-cross-testsuite_2.32.bb b/meta/recipes-devtools/binutils/binutils-cross-testsuite_2.32.bb
new file mode 100644
index 0000000000..233d981af2
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils-cross-testsuite_2.32.bb
@@ -0,0 +1,25 @@
+require binutils-cross_${PV}.bb
+
+PN = "binutils-cross-testsuite-${TARGET_ARCH}"
+
+PROVIDES = ""
+
+DEPENDS += "dejagnu-native expect-native"
+
+DEPENDS += "virtual/${TARGET_PREFIX}gcc"
+DEPENDS += "virtual/${TARGET_PREFIX}compilerlibs"
+DEPENDS += "virtual/libc"
+
+# these are needed for testsuite
+export CC_FOR_TARGET = "${TARGET_PREFIX}gcc"
+export CXX_FOR_TARGET = "${TARGET_PREFIX}g++"
+export GCC_FOR_TARGET = "${TARGET_PREFIX}gcc"
+
+EXTRA_OEMAKE_prepend_task-check = "${PARALLEL_MAKE} "
+
+do_check[dirs] = "${B}"
+do_check() {
+    oe_runmake check
+}
+addtask check before do_build after do_compile
+
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
index 96334e54b4..617e1b5f53 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -17,7 +17,8 @@ python extract_stashed_builddir () {
     src = d.expand("${COMPONENTS_DIR}/${BUILD_ARCH}/gcc-stashed-builddir-${TARGET_SYS}")
     dest = d.getVar("B")
     oe.path.copyhardlinktree(src, dest)
-    staging_processfixme([src + "/fixmepath"], dest, dest, dest, d)
+    #staging_processfixme([src + "/fixmepath"], dest, dest, dest, d)
+    staging_processfixme([src + "/fixmepath"], dest, d.getVar("RECIPE_SYSROOT"), d.getVar("RECIPE_SYSROOT_NATIVE"), d)
 }
 
 def get_gcc_float_setting(bb, d):
diff --git a/meta/recipes-devtools/gcc/gcc-cross-testsuite_9.1.bb b/meta/recipes-devtools/gcc/gcc-cross-testsuite_9.1.bb
new file mode 100644
index 0000000000..e497fce746
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-cross-testsuite_9.1.bb
@@ -0,0 +1,37 @@
+require recipes-devtools/gcc/gcc-${PV}.inc
+require gcc-cross.inc
+
+PN = "gcc-cross-testsuite-${TARGET_ARCH}"
+
+PROVIDES = ""
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "dejagnu-native expect-native"
+DEPENDS += "qemu-native"
+
+DEPENDS += "virtual/libc"
+DEPENDS += "virtual/${TARGET_PREFIX}compilerlibs"
+
+require gcc-testsuite.inc
+
+EXTRACONFFUNCS += "extract_stashed_builddir"
+do_configure[depends] += "${COMPILERDEP}"
+
+do_configure() {
+}
+
+do_compile[noexec] = "1"
+do_install[noexec] = "1"
+do_package[noexec] = "1"
+
+EXTRA_OEMAKE_prepend_task-check = "${PARALLEL_MAKE} "
+
+do_check[prefuncs] += "check_prepare"
+do_check[dirs] = "${WORKDIR}/dejagnu ${B}"
+do_check() {
+    export DEJAGNU="${WORKDIR}/dejagnu/site.exp"
+    oe_runmake check-gcc check-g++ RUNTESTFLAGS="--target_board=qemu-linux-user"
+    #oe_runmake check-gcc check-g++ RUNTESTFLAGS="--target_board=linux-ssh"
+}
+addtask check before do_build after do_configure
+
diff --git a/meta/recipes-devtools/gcc/gcc-runtime-testsuite_9.1.bb b/meta/recipes-devtools/gcc/gcc-runtime-testsuite_9.1.bb
new file mode 100644
index 0000000000..9f36649e5e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-runtime-testsuite_9.1.bb
@@ -0,0 +1,37 @@
+require gcc-runtime_${PV}.bb
+
+PROVIDES = ""
+DEPENDS += "dejagnu-native expect-native"
+DEPENDS += "qemu-native"
+
+require gcc-testsuite.inc
+
+DEPENDS += "gcc-runtime"
+
+python () {
+    check = []
+    for i in d.getVar("RUNTIMETARGET").split():
+        check.append("check-target-{0}".format(i))
+    d.setVar("RUNTIMETARGET_CHECK", " ".join(check))
+}
+
+do_configure_append() {
+    # HACK: this works around the configure setting CXX with -nostd* args
+    sed -i 's/-nostdinc++ -nostdlib++//g' $(find ${B} -name testsuite_flags | head -1)
+}
+
+EXTRA_OEMAKE_prepend_task-check = "${PARALLEL_MAKE} "
+
+do_check[prefuncs] += "check_prepare"
+do_check[dirs] = "${WORKDIR}/dejagnu ${B}"
+do_check() {
+    export DEJAGNU="${WORKDIR}/dejagnu/site.exp"
+
+    # no test should need more that 10G of memory, this prevents tests like pthread7-rope from memory leaking
+    ulimit -Sm 10485760
+
+    oe_runmake ${RUNTIMETARGET_CHECK} RUNTESTFLAGS="--target_board=qemu-linux-user"
+    #oe_runmake ${RUNTIMETARGET_CHECK} RUNTESTFLAGS="--target_board=linux-ssh"
+}
+addtask check before do_build after do_compile
+
diff --git a/meta/recipes-devtools/gcc/gcc-testsuite.inc b/meta/recipes-devtools/gcc/gcc-testsuite.inc
new file mode 100644
index 0000000000..1acf2c90b1
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-testsuite.inc
@@ -0,0 +1,65 @@
+inherit qemu
+
+python check_prepare() {
+    def generate_qemu_linux_user_config(d):
+        content = []
+        content.append('load_generic_config "sim"')
+        content.append('load_base_board_description "basic-sim"')
+        content.append('process_multilib_options ""')
+
+        # qemu args
+        qemu_binary = qemu_target_binary(d)
+        qemu_binary = bb.utils.which(d.getVar("PATH"), qemu_binary)
+        if qemu_binary is None:
+            bb.fatal("Missing target qemu linux-user binary")
+
+        args = []
+        args += (d.getVar("QEMU_OPTIONS") or "").split()
+        args += ["-L", d.getVar("RECIPE_SYSROOT")]
+        #args += ["-E", "LD_DEBUG=all"]
+        args += ["-E", "LD_LIBRARY_PATH={0}".format(":".join(["/usr/lib", "/lib"]))]
+
+        content.append('set_board_info is_simulator 1')
+        content.append('set_board_info sim "{0}"'.format(qemu_binary))
+        content.append('set_board_info sim,options "{0}"'.format(" ".join(args)))
+
+        # target build/test config
+        content.append('set_board_info target_install {%s}' % d.getVar("TARGET_SYS"))
+        content.append('set_board_info ldscript ""')
+        #content.append('set_board_info needs_status_wrapper 1') # qemu-linux-user return codes work, and abort works fine
+        content.append('set_board_info gcc,stack_size 16834')
+        content.append('set_board_info gdb,nosignals 1')
+        content.append('set_board_info gcc,timeout 60')
+
+        return "\n".join(content)
+
+    def generate_remote_ssh_linux_config(d):
+        content = []
+        content.append('load_generic_config "unix"')
+        content.append("set_board_info hostname {0}".format("localhost"))
+        content.append("set_board_info username {0}".format("root"))
+
+        port = "2222"
+        content.append("set_board_info rsh_prog \"/usr/bin/ssh -p {0} -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no\"".format(port))
+        content.append("set_board_info rcp_prog \"/usr/bin/scp -P {0} -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no\"".format(port))
+
+        return "\n".join(content)
+
+    dejagnudir = d.expand("${WORKDIR}/dejagnu")
+    if not os.path.isdir(dejagnudir):
+        os.makedirs(dejagnudir)
+
+    # write out target qemu board config
+    with open(os.path.join(dejagnudir, "qemu-linux-user.exp"), "w") as f:
+        f.write(generate_qemu_linux_user_config(d))
+
+    # write out target ssh board config
+    with open(os.path.join(dejagnudir, "linux-ssh.exp"), "w") as f:
+        f.write(generate_remote_ssh_linux_config(d))
+
+    # generate site.exp to provide boards
+    with open(os.path.join(dejagnudir, "site.exp"), "w") as f:
+        f.write("lappend boards_dir {0}\n".format(dejagnudir))
+        f.write("set CFLAGS_FOR_TARGET \"{0}\"\n".format(d.getVar("TOOLCHAIN_OPTIONS") + " " + d.getVar("TUNE_CCARGS")))
+}
+
---
2.20.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-06 11:39 [RFC PATCH] Add gnu testsuite execution for OEQA Nathan Rossi
@ 2019-07-06 12:52 ` Richard Purdie
  2019-07-08 20:55   ` Alejandro Enedino Hernandez Samaniego
  2019-07-09 10:43   ` Nathan Rossi
  2019-07-09 11:16 ` Burton, Ross
  1 sibling, 2 replies; 15+ messages in thread
From: Richard Purdie @ 2019-07-06 12:52 UTC (permalink / raw)
  To: Nathan Rossi, openembedded-core

On Sat, 2019-07-06 at 11:39 +0000, Nathan Rossi wrote:
> This patch is an RFC for adding support to execute the gnu test suites for
> binutils, gcc and glibc. With the intention for enabling automated test running
> of these test suites within the OEQA framework such that they can be executed by
> the Yocto Autobuilder.
> 
> Please note that this patch is not a complete implementation and needs
> additional work as well as changes based on comments and feedback from this RFC.

This is rather cool, thanks!

Looking at this was on my todo list once we got the existing OEQA,
ptest and ltp setups working well. I'm very happy to have been beaten
to it though.

> The test suites covered need significant resources or build artifacts such
> that running them on the target is undesirable which rules out the use of ptest.
> Because of this the test suites can be run on the build host and if necessary
> call out to the target.
> 
> The following implementation creates a number of recipes that are used to
> build/execute the test suites for the different components. The reason for
> creating separate recipes is primarily due to dependencies and the need for
> components in the sysroot. For example binutils has tests that use the C
> compiler however binutils is a dependency for the C compiler and thus would
> cause a dependency loop. The issue with sysroots occurs with dependence on
> `*-initial` recipes and the test suites needing the non-initial version.

I think this means you're working with something pre-warrior as we got
rid of most of the *-initial recipes apart from libgcc-initial.

> Some issues with splitting the recipes:
>  - Rebuilds the recipe
>    - Like gcc-cross-testsuite in this patch, could use a stashed builddir
>  - Source is duplicated
>    - gcc gets around this with shared source
>  - Requires having the recipe files and maintaining them
>    - Multiple versions of recipes
>    - Multiple variants of recipes (-cross, -crosssdk, -native if desired)

It might be possible to have multiple tasks in these recipes and have
the later tasks depend on other pieces of the system like the C
compiler, thereby avoiding the need for splitting if only the later
tasks have the dependencies. Not sure if it would work or not but may
be worth exploring.

> Target execution is another issue with the test suites. Note that binutils
> however does not require any target execution. In this patch both
> qemu-linux-user and ssh target execution solutions are provided. For the
> purposes of OE, qemu-linux-user may suffice as it has great success at executing
> gcc and gcc-runtime tests with acceptable success at executing the glibc tests.

I feel fairly strongly that we probably want to execute these kinds of
tests under qemu system mode, not the user mode. The reason is that we
want to be as close to the target environment as we can be and that
qemu-user testing is at least as much of a test of qemu's emulation
that it is the behaviour of the compiler or libc (libc in particular).
I was thinking this and then later read you confirmed my suspicions
below...

> The glibc test suite can be problematic to execute for a few reasons:
>  - Requires access to the exact same filesystem as the build host
>    - On physical targets and QEMU this requires NFS mounts

We do have unfs support already under qemu which might make this
possible.

>  - Relies on exact syscall behaviour
>    - Causes some issues where there are differences between qemu-linux-user and
>      the target architectures kernel

Right, this one worries me and pushes me to want to use qemu system
mode.

>  - Can consume significant resources (e.g. OOM, or worse trigger bugs/panics in
>    kernel drivers)

Any rough guide to what significant is here? ptest needs 1GB memory for
example. qemu-system mode should limit that to the VMs at least?

>  - Slow to execute
>    - With QEMU system emulation it can take many hours

We do have KVM acceleration for x86 and arm FWIW which is probably
where we'd start testing this on the autobuilder.

>    - With some physical target architectures it can take days (e.g. microblaze)
> 
> The significantly increased execution speed of qemu-linux-user vs qemu system
> with glibc, and the ability for qemu-linux-user to be executed in parallel with
> the gcc test suite makes it a strong solution for continuous integration
> testing.

Was that with or without KVM?

> The following table shows results for the major test suite components running
> with qemu-linux-user execution. The numbers represent 'failed tests'/'total
> tests'. The machines used to run the tests are the `qemu*` machine for the
> associated architecture, not all qemu machines available in oe-core were tested.
> It is important to note that these results are only indicative of
> qemu-linux-user behaviour and that there are a number of test failures that are
> due to issues not specific to qemu-linux-user.
> 
>         | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
> x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
> arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
> aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
> powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
> mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
> riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847

I'd be interested to know how these numbers compare to the ssh
execution...

The binutils results look good! :)

> This patch also introduces some OEQA test cases which cover running the test
> suites. However in this specific patch it does not include any implementation
> for the automated setup of qemu system emulation testing with runqemu and NFS
> mounting for glibc tests. Also not included in these test cases is any known
> test failure filtering.

The known test failure filtering is something we can use the OEQA
backend for, I'd envisage this being intergrated in a similar way to
the way we added ptest/ltp/ltp-posix there.

> I would also be interested in the opinion with regards to whether these test
> suites should be executed as part of the existing Yocto Autobuilder instance.

Short answer is yes. We won't run them all the time but when it makes
sense and I'd happily see the autobuilder apart to be able to trigger
these appropriately. We can probably run the KVM accelerated arches
more often than the others.

Plenty of implementation details to further discuss but this is great
to see!

Cheers,

Richard



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-06 12:52 ` Richard Purdie
@ 2019-07-08 20:55   ` Alejandro Enedino Hernandez Samaniego
  2019-07-09 10:59     ` Nathan Rossi
  2019-07-09 10:43   ` Nathan Rossi
  1 sibling, 1 reply; 15+ messages in thread
From: Alejandro Enedino Hernandez Samaniego @ 2019-07-08 20:55 UTC (permalink / raw)
  To: Richard Purdie; +Cc: OE-core

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

Hey guys,

On Sat, Jul 6, 2019 at 5:52 AM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Sat, 2019-07-06 at 11:39 +0000, Nathan Rossi wrote:
> > This patch is an RFC for adding support to execute the gnu test suites
> for
> > binutils, gcc and glibc. With the intention for enabling automated test
> running
> > of these test suites within the OEQA framework such that they can be
> executed by
> > the Yocto Autobuilder.
> >
> > Please note that this patch is not a complete implementation and needs
> > additional work as well as changes based on comments and feedback from
> this RFC.
>
> This is rather cool, thanks!
>
> Looking at this was on my todo list once we got the existing OEQA,
> ptest and ltp setups working well. I'm very happy to have been beaten
> to it though.
>
> > The test suites covered need significant resources or build artifacts
> such
> > that running them on the target is undesirable which rules out the use
> of ptest.
> > Because of this the test suites can be run on the build host and if
> necessary
> > call out to the target.
> >
> > The following implementation creates a number of recipes that are used to
> > build/execute the test suites for the different components. The reason
> for
> > creating separate recipes is primarily due to dependencies and the need
> for
> > components in the sysroot. For example binutils has tests that use the C
> > compiler however binutils is a dependency for the C compiler and thus
> would
> > cause a dependency loop. The issue with sysroots occurs with dependence
> on
> > `*-initial` recipes and the test suites needing the non-initial version.
>
> I think this means you're working with something pre-warrior as we got
> rid of most of the *-initial recipes apart from libgcc-initial.
>

 Yup, I agree with this, and yes, we still have initial recipes, which is
in what Nathan based his work.


> > Some issues with splitting the recipes:
> >  - Rebuilds the recipe
> >    - Like gcc-cross-testsuite in this patch, could use a stashed builddir
> >  - Source is duplicated
> >    - gcc gets around this with shared source
> >  - Requires having the recipe files and maintaining them
> >    - Multiple versions of recipes
> >    - Multiple variants of recipes (-cross, -crosssdk, -native if desired)
>
> It might be possible to have multiple tasks in these recipes and have
> the later tasks depend on other pieces of the system like the C
> compiler, thereby avoiding the need for splitting if only the later
> tasks have the dependencies. Not sure if it would work or not but may
> be worth exploring.
>

Worth exploring but might end up being more convoluted than necessary IMO.
Benefit vs Complication issue.



> > Target execution is another issue with the test suites. Note that
> binutils
> > however does not require any target execution. In this patch both
> > qemu-linux-user and ssh target execution solutions are provided. For the
> > purposes of OE, qemu-linux-user may suffice as it has great success at
> executing
> > gcc and gcc-runtime tests with acceptable success at executing the glibc
> tests.
>
> I feel fairly strongly that we probably want to execute these kinds of
> tests under qemu system mode, not the user mode. The reason is that we
> want to be as close to the target environment as we can be and that
> qemu-user testing is at least as much of a test of qemu's emulation
> that it is the behaviour of the compiler or libc (libc in particular).
> I was thinking this and then later read you confirmed my suspicions
> below...
>

I believe the QEMU recipe splitting is also new in the tree, and Nathan
isn't basing his work on that,
so there might be some issues there.


>
> > The glibc test suite can be problematic to execute for a few reasons:
> >  - Requires access to the exact same filesystem as the build host
> >    - On physical targets and QEMU this requires NFS mounts
>
> We do have unfs support already under qemu which might make this
> possible.
>
> >  - Relies on exact syscall behaviour
> >    - Causes some issues where there are differences between
> qemu-linux-user and
> >      the target architectures kernel
>
> Right, this one worries me and pushes me to want to use qemu system
> mode.
>
> >  - Can consume significant resources (e.g. OOM, or worse trigger
> bugs/panics in
> >    kernel drivers)
>
> Any rough guide to what significant is here? ptest needs 1GB memory for
> example. qemu-system mode should limit that to the VMs at least?
>
> >  - Slow to execute
> >    - With QEMU system emulation it can take many hours
>
> We do have KVM acceleration for x86 and arm FWIW which is probably
> where we'd start testing this on the autobuilder.
>

Excuse me if I'm mistaken, but would this be something similar to what
we did for python3 optimization?


>
> >    - With some physical target architectures it can take days (e.g.
> microblaze)
> >
> > The significantly increased execution speed of qemu-linux-user vs qemu
> system
> > with glibc, and the ability for qemu-linux-user to be executed in
> parallel with
> > the gcc test suite makes it a strong solution for continuous integration
> > testing.
>
> Was that with or without KVM?
>
> > The following table shows results for the major test suite components
> running
> > with qemu-linux-user execution. The numbers represent 'failed
> tests'/'total
> > tests'. The machines used to run the tests are the `qemu*` machine for
> the
> > associated architecture, not all qemu machines available in oe-core were
> tested.
> > It is important to note that these results are only indicative of
> > qemu-linux-user behaviour and that there are a number of test failures
> that are
> > due to issues not specific to qemu-linux-user.
> >
> >         | gcc          | g++          | libstdc++   | binutils    | gas
>        | ld          | glibc
> > x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |
>  0/ 1256 |   166/ 1975 |  1423/ 5991
> > arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |
>  0/  872 |   155/ 1479 |    64/ 5130
> > aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |
>  0/  442 |   157/ 1474 |    76/ 5882
> > powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |
>  1/  265 |   157/ 1352 |  1218/ 5110
> > mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |
> 43/ 7245 |   803/ 1634 |  2032/ 5847
> > riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |
>  0/  257 |   152/ 1062 |    88/ 5847
>
> I'd be interested to know how these numbers compare to the ssh
> execution...
>
> The binutils results look good! :)
>
>
This is awesome!, some are a little scary though (percentage wise)


> > This patch also introduces some OEQA test cases which cover running the
> test
> > suites. However in this specific patch it does not include any
> implementation
> > for the automated setup of qemu system emulation testing with runqemu
> and NFS
> > mounting for glibc tests. Also not included in these test cases is any
> known
> > test failure filtering.
>
> The known test failure filtering is something we can use the OEQA
> backend for, I'd envisage this being intergrated in a similar way to
> the way we added ptest/ltp/ltp-posix there.
>
> > I would also be interested in the opinion with regards to whether these
> test
> > suites should be executed as part of the existing Yocto Autobuilder
> instance.
>
> Short answer is yes. We won't run them all the time but when it makes
> sense and I'd happily see the autobuilder apart to be able to trigger
> these appropriately. We can probably run the KVM accelerated arches
> more often than the others.
>

Would we separate test cases into different sets/suites based on
importance?, and yes
I'd love to see this in the Yocto AB.


> Plenty of implementation details to further discuss but this is great
> to see!
>
> Cheers,
>
> Richard
>
>
This looks good, great work Nathan!, my only other comment would be that we
would
probably need two versions of the patches (one for thud) and one for
master/warrior where
some of the changes to *-initial recipes and qemu- system/user have
happened already.

Regards,

Alejandro



> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


-- 
*M.S. Alejandro Enedino Herna**ndez Samaniego*

[-- Attachment #2: Type: text/html, Size: 11380 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-06 12:52 ` Richard Purdie
  2019-07-08 20:55   ` Alejandro Enedino Hernandez Samaniego
@ 2019-07-09 10:43   ` Nathan Rossi
  2019-07-24 12:30     ` Nathan Rossi
  1 sibling, 1 reply; 15+ messages in thread
From: Nathan Rossi @ 2019-07-09 10:43 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-core

On Sat, 6 Jul 2019 at 22:52, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Sat, 2019-07-06 at 11:39 +0000, Nathan Rossi wrote:
> > This patch is an RFC for adding support to execute the gnu test suites for
> > binutils, gcc and glibc. With the intention for enabling automated test running
> > of these test suites within the OEQA framework such that they can be executed by
> > the Yocto Autobuilder.
> >
> > Please note that this patch is not a complete implementation and needs
> > additional work as well as changes based on comments and feedback from this RFC.
>
> This is rather cool, thanks!
>
> Looking at this was on my todo list once we got the existing OEQA,
> ptest and ltp setups working well. I'm very happy to have been beaten
> to it though.
>
> > The test suites covered need significant resources or build artifacts such
> > that running them on the target is undesirable which rules out the use of ptest.
> > Because of this the test suites can be run on the build host and if necessary
> > call out to the target.
> >
> > The following implementation creates a number of recipes that are used to
> > build/execute the test suites for the different components. The reason for
> > creating separate recipes is primarily due to dependencies and the need for
> > components in the sysroot. For example binutils has tests that use the C
> > compiler however binutils is a dependency for the C compiler and thus would
> > cause a dependency loop. The issue with sysroots occurs with dependence on
> > `*-initial` recipes and the test suites needing the non-initial version.
>
> I think this means you're working with something pre-warrior as we got
> rid of most of the *-initial recipes apart from libgcc-initial.

I have been working against master (maybe a few days old). However I
hit the sysroot collision in gcc-cross with what I thought was a
-initial recipe. So I split it out and kept moving ahead.

Turns out it was just one file, specifically an empty limits.h that is
created by the gcc-cross recipe itself.
(http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc-cross.inc#n49)

>
> > Some issues with splitting the recipes:
> >  - Rebuilds the recipe
> >    - Like gcc-cross-testsuite in this patch, could use a stashed builddir
> >  - Source is duplicated
> >    - gcc gets around this with shared source
> >  - Requires having the recipe files and maintaining them
> >    - Multiple versions of recipes
> >    - Multiple variants of recipes (-cross, -crosssdk, -native if desired)
>
> It might be possible to have multiple tasks in these recipes and have
> the later tasks depend on other pieces of the system like the C
> compiler, thereby avoiding the need for splitting if only the later
> tasks have the dependencies. Not sure if it would work or not but may
> be worth exploring.

Initially I had started out with binutils having the do_check task
which depended on the populate_sysroot task of the associated
dependencies and this was working well for binutils at least. The only
concern I had with this was whether tainting the recipe sysroots would
be problematic?

Given the sysroot/-initial issue with gcc was not a dependency problem
I have tried with the check tasks in gcc-cross and gcc-runtime and
there does not appear to have any issues. So splitting the recipes for
binutils, gcc-cross and gcc-runtime is not necessary.

For glibc the sysroot has libgcc-initial, so the sysroot collision is
still a problem for it.

>
> > Target execution is another issue with the test suites. Note that binutils
> > however does not require any target execution. In this patch both
> > qemu-linux-user and ssh target execution solutions are provided. For the
> > purposes of OE, qemu-linux-user may suffice as it has great success at executing
> > gcc and gcc-runtime tests with acceptable success at executing the glibc tests.
>
> I feel fairly strongly that we probably want to execute these kinds of
> tests under qemu system mode, not the user mode. The reason is that we
> want to be as close to the target environment as we can be and that
> qemu-user testing is at least as much of a test of qemu's emulation
> that it is the behaviour of the compiler or libc (libc in particular).
> I was thinking this and then later read you confirmed my suspicions
> below...
>
> > The glibc test suite can be problematic to execute for a few reasons:
> >  - Requires access to the exact same filesystem as the build host
> >    - On physical targets and QEMU this requires NFS mounts
>
> We do have unfs support already under qemu which might make this
> possible.

unfs works great and I was using it for testing out the ssh support.
However I did notice that is does rely on the host having rpcbind
installed. This does prevent running the tests without root (even if
using slirp for qemu).

>
> >  - Relies on exact syscall behaviour
> >    - Causes some issues where there are differences between qemu-linux-user and
> >      the target architectures kernel
>
> Right, this one worries me and pushes me to want to use qemu system
> mode.
>
> >  - Can consume significant resources (e.g. OOM, or worse trigger bugs/panics in
> >    kernel drivers)
>
> Any rough guide to what significant is here? ptest needs 1GB memory for
> example. qemu-system mode should limit that to the VMs at least?

This is a tricky one, and my comment is mostly based on prior
experience with running glibc tests on less common targets (like
microblaze). Where the stability of the kernel when handling large
amount of NFS traffic alongside cpu/memory heavy tasks would cause
panics and some times kernel hangs. I am not sure how generally this
applies though, will report on this once I have some tests results
with more of the qemu machines running via system emulation/ssh.

>
> >  - Slow to execute
> >    - With QEMU system emulation it can take many hours
>
> We do have KVM acceleration for x86 and arm FWIW which is probably
> where we'd start testing this on the autobuilder.
>
> >    - With some physical target architectures it can take days (e.g. microblaze)
> >
> > The significantly increased execution speed of qemu-linux-user vs qemu system
> > with glibc, and the ability for qemu-linux-user to be executed in parallel with
> > the gcc test suite makes it a strong solution for continuous integration
> > testing.
>
> Was that with or without KVM?

Without KVM. I will add KVM testing with the system emulation tests I
run, to get a better idea on exact performance differences.

>
> > The following table shows results for the major test suite components running
> > with qemu-linux-user execution. The numbers represent 'failed tests'/'total
> > tests'. The machines used to run the tests are the `qemu*` machine for the
> > associated architecture, not all qemu machines available in oe-core were tested.
> > It is important to note that these results are only indicative of
> > qemu-linux-user behaviour and that there are a number of test failures that are
> > due to issues not specific to qemu-linux-user.
> >
> >         | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
> > x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
> > arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
> > aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
> > powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
> > mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
> > riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847
>
> I'd be interested to know how these numbers compare to the ssh
> execution...

I will setup some OEQA automation to get results for this. It might
take me a little bit since they can be slow to run.

>
> The binutils results look good! :)
>
> > This patch also introduces some OEQA test cases which cover running the test
> > suites. However in this specific patch it does not include any implementation
> > for the automated setup of qemu system emulation testing with runqemu and NFS
> > mounting for glibc tests. Also not included in these test cases is any known
> > test failure filtering.
>
> The known test failure filtering is something we can use the OEQA
> backend for, I'd envisage this being intergrated in a similar way to
> the way we added ptest/ltp/ltp-posix there.

I am not very familiar with the OEQA backend, and was not able to find
anything about test filtering in lib/oeqa (just searching). Maybe I am
looking in the wrong place, any pointers for where this part of the
backend is located?

Thanks,
Nathan



>
> > I would also be interested in the opinion with regards to whether these test
> > suites should be executed as part of the existing Yocto Autobuilder instance.
>
> Short answer is yes. We won't run them all the time but when it makes
> sense and I'd happily see the autobuilder apart to be able to trigger
> these appropriately. We can probably run the KVM accelerated arches
> more often than the others.
>
> Plenty of implementation details to further discuss but this is great
> to see!
>
> Cheers,
>
> Richard
>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-08 20:55   ` Alejandro Enedino Hernandez Samaniego
@ 2019-07-09 10:59     ` Nathan Rossi
  0 siblings, 0 replies; 15+ messages in thread
From: Nathan Rossi @ 2019-07-09 10:59 UTC (permalink / raw)
  To: Alejandro Enedino Hernandez Samaniego; +Cc: OE-core

On Tue, 9 Jul 2019 at 06:55, Alejandro Enedino Hernandez Samaniego
<aehs29@gmail.com> wrote:
>
> Hey guys,
>
> On Sat, Jul 6, 2019 at 5:52 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>
>> On Sat, 2019-07-06 at 11:39 +0000, Nathan Rossi wrote:
>> > This patch is an RFC for adding support to execute the gnu test suites for
>> > binutils, gcc and glibc. With the intention for enabling automated test running
>> > of these test suites within the OEQA framework such that they can be executed by
>> > the Yocto Autobuilder.
>> >
>> > Please note that this patch is not a complete implementation and needs
>> > additional work as well as changes based on comments and feedback from this RFC.
>>
>> This is rather cool, thanks!
>>
>> Looking at this was on my todo list once we got the existing OEQA,
>> ptest and ltp setups working well. I'm very happy to have been beaten
>> to it though.
>>
>> > The test suites covered need significant resources or build artifacts such
>> > that running them on the target is undesirable which rules out the use of ptest.
>> > Because of this the test suites can be run on the build host and if necessary
>> > call out to the target.
>> >
>> > The following implementation creates a number of recipes that are used to
>> > build/execute the test suites for the different components. The reason for
>> > creating separate recipes is primarily due to dependencies and the need for
>> > components in the sysroot. For example binutils has tests that use the C
>> > compiler however binutils is a dependency for the C compiler and thus would
>> > cause a dependency loop. The issue with sysroots occurs with dependence on
>> > `*-initial` recipes and the test suites needing the non-initial version.
>>
>> I think this means you're working with something pre-warrior as we got
>> rid of most of the *-initial recipes apart from libgcc-initial.
>
>
>  Yup, I agree with this, and yes, we still have initial recipes, which is in what Nathan based his work.
>
>>
>> > Some issues with splitting the recipes:
>> >  - Rebuilds the recipe
>> >    - Like gcc-cross-testsuite in this patch, could use a stashed builddir
>> >  - Source is duplicated
>> >    - gcc gets around this with shared source
>> >  - Requires having the recipe files and maintaining them
>> >    - Multiple versions of recipes
>> >    - Multiple variants of recipes (-cross, -crosssdk, -native if desired)
>>
>> It might be possible to have multiple tasks in these recipes and have
>> the later tasks depend on other pieces of the system like the C
>> compiler, thereby avoiding the need for splitting if only the later
>> tasks have the dependencies. Not sure if it would work or not but may
>> be worth exploring.
>
>
> Worth exploring but might end up being more convoluted than necessary IMO.
> Benefit vs Complication issue.
>
>
>>
>> > Target execution is another issue with the test suites. Note that binutils
>> > however does not require any target execution. In this patch both
>> > qemu-linux-user and ssh target execution solutions are provided. For the
>> > purposes of OE, qemu-linux-user may suffice as it has great success at executing
>> > gcc and gcc-runtime tests with acceptable success at executing the glibc tests.
>>
>> I feel fairly strongly that we probably want to execute these kinds of
>> tests under qemu system mode, not the user mode. The reason is that we
>> want to be as close to the target environment as we can be and that
>> qemu-user testing is at least as much of a test of qemu's emulation
>> that it is the behaviour of the compiler or libc (libc in particular).
>> I was thinking this and then later read you confirmed my suspicions
>> below...
>
>
> I believe the QEMU recipe splitting is also new in the tree, and Nathan isn't basing his work on that,
> so there might be some issues there.

I have been working against a relatively recent master, and have been
rebasing every now and again. The qemu system/user split likely will
not be a big problem, since at least at this point I have kept all the
qemu system tooling as runqemu setup in OEQA. So would work fine on
master/warrior/thud.

>
>>
>>
>> > The glibc test suite can be problematic to execute for a few reasons:
>> >  - Requires access to the exact same filesystem as the build host
>> >    - On physical targets and QEMU this requires NFS mounts
>>
>> We do have unfs support already under qemu which might make this
>> possible.
>>
>> >  - Relies on exact syscall behaviour
>> >    - Causes some issues where there are differences between qemu-linux-user and
>> >      the target architectures kernel
>>
>> Right, this one worries me and pushes me to want to use qemu system
>> mode.
>>
>> >  - Can consume significant resources (e.g. OOM, or worse trigger bugs/panics in
>> >    kernel drivers)
>>
>> Any rough guide to what significant is here? ptest needs 1GB memory for
>> example. qemu-system mode should limit that to the VMs at least?
>>
>> >  - Slow to execute
>> >    - With QEMU system emulation it can take many hours
>>
>> We do have KVM acceleration for x86 and arm FWIW which is probably
>> where we'd start testing this on the autobuilder.
>
>
> Excuse me if I'm mistaken, but would this be something similar to what
> we did for python3 optimization?
>
>>
>>
>> >    - With some physical target architectures it can take days (e.g. microblaze)
>> >
>> > The significantly increased execution speed of qemu-linux-user vs qemu system
>> > with glibc, and the ability for qemu-linux-user to be executed in parallel with
>> > the gcc test suite makes it a strong solution for continuous integration
>> > testing.
>>
>> Was that with or without KVM?
>>
>> > The following table shows results for the major test suite components running
>> > with qemu-linux-user execution. The numbers represent 'failed tests'/'total
>> > tests'. The machines used to run the tests are the `qemu*` machine for the
>> > associated architecture, not all qemu machines available in oe-core were tested.
>> > It is important to note that these results are only indicative of
>> > qemu-linux-user behaviour and that there are a number of test failures that are
>> > due to issues not specific to qemu-linux-user.
>> >
>> >         | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
>> > x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
>> > arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
>> > aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
>> > powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
>> > mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
>> > riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847
>>
>> I'd be interested to know how these numbers compare to the ssh
>> execution...
>>
>> The binutils results look good! :)
>>
>
> This is awesome!, some are a little scary though (percentage wise)
>
>>
>> > This patch also introduces some OEQA test cases which cover running the test
>> > suites. However in this specific patch it does not include any implementation
>> > for the automated setup of qemu system emulation testing with runqemu and NFS
>> > mounting for glibc tests. Also not included in these test cases is any known
>> > test failure filtering.
>>
>> The known test failure filtering is something we can use the OEQA
>> backend for, I'd envisage this being intergrated in a similar way to
>> the way we added ptest/ltp/ltp-posix there.
>>
>> > I would also be interested in the opinion with regards to whether these test
>> > suites should be executed as part of the existing Yocto Autobuilder instance.
>>
>> Short answer is yes. We won't run them all the time but when it makes
>> sense and I'd happily see the autobuilder apart to be able to trigger
>> these appropriately. We can probably run the KVM accelerated arches
>> more often than the others.
>
>
> Would we separate test cases into different sets/suites based on importance?, and yes
> I'd love to see this in the Yocto AB.

It might be worth splitting out the sub component test suites, e.g.
check-gcc and check-g++ as separate OEQA test cases. Which would
probably help to run parallel system qemu instances. However it would
be more complicated to split further.

>
>>
>> Plenty of implementation details to further discuss but this is great
>> to see!
>>
>> Cheers,
>>
>> Richard
>>
>
> This looks good, great work Nathan!, my only other comment would be that we would
> probably need two versions of the patches (one for thud) and one for master/warrior where
> some of the changes to *-initial recipes and qemu- system/user have happened already.

Certainly possible to make a thud version, but best to do that once a
version for master is completed.

Thanks,
Nathan

>
> Regards,
>
> Alejandro
>
>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> M.S. Alejandro Enedino Hernandez Samaniego


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-06 11:39 [RFC PATCH] Add gnu testsuite execution for OEQA Nathan Rossi
  2019-07-06 12:52 ` Richard Purdie
@ 2019-07-09 11:16 ` Burton, Ross
  2019-07-09 11:47   ` Nathan Rossi
  1 sibling, 1 reply; 15+ messages in thread
From: Burton, Ross @ 2019-07-09 11:16 UTC (permalink / raw)
  To: Nathan Rossi; +Cc: OE-core

This is awesome!

On Sat, 6 Jul 2019 at 12:39, Nathan Rossi <nathan@nathanrossi.com> wrote:
>         | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
> x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
> arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
> aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
> powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
> mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
> riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847

So what I'm really interested in is what those numbers look like for
e.g. x86-64 on real hardware: are the test suites always failing a
bit, or are these indicative of problems we've introduced?

Ross


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-09 11:16 ` Burton, Ross
@ 2019-07-09 11:47   ` Nathan Rossi
  2019-07-09 11:54     ` Burton, Ross
  2019-07-09 20:12     ` Khem Raj
  0 siblings, 2 replies; 15+ messages in thread
From: Nathan Rossi @ 2019-07-09 11:47 UTC (permalink / raw)
  To: Burton, Ross; +Cc: OE-core

On Tue, 9 Jul 2019 at 21:16, Burton, Ross <ross.burton@intel.com> wrote:
>
> This is awesome!
>
> On Sat, 6 Jul 2019 at 12:39, Nathan Rossi <nathan@nathanrossi.com> wrote:
> >         | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
> > x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
> > arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
> > aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
> > powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
> > mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
> > riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847
>
> So what I'm really interested in is what those numbers look like for
> e.g. x86-64 on real hardware: are the test suites always failing a
> bit, or are these indicative of problems we've introduced?

Just to clarify, by real hardware are you interested in the tests
running against a system running with a oe distro + kernel. Or just
running on e.g. the build host?

As for the failing tests, do not put to much emphasis on the values
provided. I am sure there are a number of tests that are failing due
to minor configuration issues that simply need a deeper look at the
test result and output to fix the issue. And the large number of
failures for powerpc are due to qemu user failing due to illegal
instruction.

The goal would be to get the results similar to what other
users/distro get, by reviewing results posted here:
https://gcc.gnu.org/ml/gcc-testresults/.
And for glibc the results from: https://sourceware.org/glibc/wiki/Release/2.29

Thanks,
Nathan


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-09 11:47   ` Nathan Rossi
@ 2019-07-09 11:54     ` Burton, Ross
  2019-07-09 20:12     ` Khem Raj
  1 sibling, 0 replies; 15+ messages in thread
From: Burton, Ross @ 2019-07-09 11:54 UTC (permalink / raw)
  To: Nathan Rossi; +Cc: OE-core

On Tue, 9 Jul 2019 at 12:47, Nathan Rossi <nathan@nathanrossi.com> wrote:
> Just to clarify, by real hardware are you interested in the tests
> running against a system running with a oe distro + kernel. Or just
> running on e.g. the build host?
>
> As for the failing tests, do not put to much emphasis on the values
> provided. I am sure there are a number of tests that are failing due
> to minor configuration issues that simply need a deeper look at the
> test result and output to fix the issue. And the large number of
> failures for powerpc are due to qemu user failing due to illegal
> instruction.
>
> The goal would be to get the results similar to what other
> users/distro get, by reviewing results posted here:
> https://gcc.gnu.org/ml/gcc-testresults/.
> And for glibc the results from: https://sourceware.org/glibc/wiki/Release/2.29

Ah that's useful that they publish those.  So the test results for
2.29 on x86-64 are:

   5961 PASS
     21 UNSUPPORTED
     17 XFAIL
      2 XPASS

And your report has 1423 failures, so *something* is broken.  As you
say, some flaw in qemu-user is most likely the culprit there.  Compare
to the ARM results:

      9 FAIL
   5041 PASS
     31 UNSUPPORTED
     17 XFAIL
      2 XPASS

Your report has 64 failures, which is much closer even with qemu-user.

Ross


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-09 11:47   ` Nathan Rossi
  2019-07-09 11:54     ` Burton, Ross
@ 2019-07-09 20:12     ` Khem Raj
  1 sibling, 0 replies; 15+ messages in thread
From: Khem Raj @ 2019-07-09 20:12 UTC (permalink / raw)
  To: Nathan Rossi; +Cc: OE-core

On Tue, Jul 9, 2019 at 4:48 AM Nathan Rossi <nathan@nathanrossi.com> wrote:
>
> On Tue, 9 Jul 2019 at 21:16, Burton, Ross <ross.burton@intel.com> wrote:
> >
> > This is awesome!
> >
> > On Sat, 6 Jul 2019 at 12:39, Nathan Rossi <nathan@nathanrossi.com> wrote:
> > >         | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
> > > x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
> > > arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
> > > aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
> > > powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
> > > mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
> > > riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847
> >
> > So what I'm really interested in is what those numbers look like for
> > e.g. x86-64 on real hardware: are the test suites always failing a
> > bit, or are these indicative of problems we've introduced?
>

these numbers id PASS/FAIL are not usual, usually it should be only
handful of failures, but this could be
some simple basic missing piece, since dejaGNU is quite picky at times.

> Just to clarify, by real hardware are you interested in the tests
> running against a system running with a oe distro + kernel. Or just
> running on e.g. the build host?
>
> As for the failing tests, do not put to much emphasis on the values
> provided. I am sure there are a number of tests that are failing due
> to minor configuration issues that simply need a deeper look at the
> test result and output to fix the issue. And the large number of
> failures for powerpc are due to qemu user failing due to illegal
> instruction.
>
> The goal would be to get the results similar to what other
> users/distro get, by reviewing results posted here:
> https://gcc.gnu.org/ml/gcc-testresults/.
> And for glibc the results from: https://sourceware.org/glibc/wiki/Release/2.29
>
> Thanks,
> Nathan
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-09 10:43   ` Nathan Rossi
@ 2019-07-24 12:30     ` Nathan Rossi
  2019-07-24 13:55       ` richard.purdie
  0 siblings, 1 reply; 15+ messages in thread
From: Nathan Rossi @ 2019-07-24 12:30 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-core

On Tue, 9 Jul 2019 at 20:43, Nathan Rossi <nathan@nathanrossi.com> wrote:
>
> On Sat, 6 Jul 2019 at 22:52, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Sat, 2019-07-06 at 11:39 +0000, Nathan Rossi wrote:
> > > This patch is an RFC for adding support to execute the gnu test suites for
> > > binutils, gcc and glibc. With the intention for enabling automated test running
> > > of these test suites within the OEQA framework such that they can be executed by
> > > the Yocto Autobuilder.
> > >
> > > Please note that this patch is not a complete implementation and needs
> > > additional work as well as changes based on comments and feedback from this RFC.
> >
> > This is rather cool, thanks!
> >
> > Looking at this was on my todo list once we got the existing OEQA,
> > ptest and ltp setups working well. I'm very happy to have been beaten
> > to it though.
> >
> > > The test suites covered need significant resources or build artifacts such
> > > that running them on the target is undesirable which rules out the use of ptest.
> > > Because of this the test suites can be run on the build host and if necessary
> > > call out to the target.
> > >
> > > The following implementation creates a number of recipes that are used to
> > > build/execute the test suites for the different components. The reason for
> > > creating separate recipes is primarily due to dependencies and the need for
> > > components in the sysroot. For example binutils has tests that use the C
> > > compiler however binutils is a dependency for the C compiler and thus would
> > > cause a dependency loop. The issue with sysroots occurs with dependence on
> > > `*-initial` recipes and the test suites needing the non-initial version.
> >
> > I think this means you're working with something pre-warrior as we got
> > rid of most of the *-initial recipes apart from libgcc-initial.
>
> I have been working against master (maybe a few days old). However I
> hit the sysroot collision in gcc-cross with what I thought was a
> -initial recipe. So I split it out and kept moving ahead.
>
> Turns out it was just one file, specifically an empty limits.h that is
> created by the gcc-cross recipe itself.
> (http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc-cross.inc#n49)
>
> >
> > > Some issues with splitting the recipes:
> > >  - Rebuilds the recipe
> > >    - Like gcc-cross-testsuite in this patch, could use a stashed builddir
> > >  - Source is duplicated
> > >    - gcc gets around this with shared source
> > >  - Requires having the recipe files and maintaining them
> > >    - Multiple versions of recipes
> > >    - Multiple variants of recipes (-cross, -crosssdk, -native if desired)
> >
> > It might be possible to have multiple tasks in these recipes and have
> > the later tasks depend on other pieces of the system like the C
> > compiler, thereby avoiding the need for splitting if only the later
> > tasks have the dependencies. Not sure if it would work or not but may
> > be worth exploring.
>
> Initially I had started out with binutils having the do_check task
> which depended on the populate_sysroot task of the associated
> dependencies and this was working well for binutils at least. The only
> concern I had with this was whether tainting the recipe sysroots would
> be problematic?
>
> Given the sysroot/-initial issue with gcc was not a dependency problem
> I have tried with the check tasks in gcc-cross and gcc-runtime and
> there does not appear to have any issues. So splitting the recipes for
> binutils, gcc-cross and gcc-runtime is not necessary.
>
> For glibc the sysroot has libgcc-initial, so the sysroot collision is
> still a problem for it.
>
> >
> > > Target execution is another issue with the test suites. Note that binutils
> > > however does not require any target execution. In this patch both
> > > qemu-linux-user and ssh target execution solutions are provided. For the
> > > purposes of OE, qemu-linux-user may suffice as it has great success at executing
> > > gcc and gcc-runtime tests with acceptable success at executing the glibc tests.
> >
> > I feel fairly strongly that we probably want to execute these kinds of
> > tests under qemu system mode, not the user mode. The reason is that we
> > want to be as close to the target environment as we can be and that
> > qemu-user testing is at least as much of a test of qemu's emulation
> > that it is the behaviour of the compiler or libc (libc in particular).
> > I was thinking this and then later read you confirmed my suspicions
> > below...
> >
> > > The glibc test suite can be problematic to execute for a few reasons:
> > >  - Requires access to the exact same filesystem as the build host
> > >    - On physical targets and QEMU this requires NFS mounts
> >
> > We do have unfs support already under qemu which might make this
> > possible.
>
> unfs works great and I was using it for testing out the ssh support.
> However I did notice that is does rely on the host having rpcbind
> installed. This does prevent running the tests without root (even if
> using slirp for qemu).
>
> >
> > >  - Relies on exact syscall behaviour
> > >    - Causes some issues where there are differences between qemu-linux-user and
> > >      the target architectures kernel
> >
> > Right, this one worries me and pushes me to want to use qemu system
> > mode.
> >
> > >  - Can consume significant resources (e.g. OOM, or worse trigger bugs/panics in
> > >    kernel drivers)
> >
> > Any rough guide to what significant is here? ptest needs 1GB memory for
> > example. qemu-system mode should limit that to the VMs at least?
>
> This is a tricky one, and my comment is mostly based on prior
> experience with running glibc tests on less common targets (like
> microblaze). Where the stability of the kernel when handling large
> amount of NFS traffic alongside cpu/memory heavy tasks would cause
> panics and some times kernel hangs. I am not sure how generally this
> applies though, will report on this once I have some tests results
> with more of the qemu machines running via system emulation/ssh.

So I only hit one major issue with the oe-core qemu* machines I tested
on when running under system emulation, specifically with
aarch64/qemuarm64.

One (or more) test in the "c" suite of gcc causes qemu to crash due to
what appears to be an internal qemu issue.

qemu outputted:
qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion
`s->gen_insn_end_off[num_insns] == off' failed.

The test that caused this was:
gcc.target/aarch64/advsimd-intrinsics/vldX.c   -O2  execution test

>
> >
> > >  - Slow to execute
> > >    - With QEMU system emulation it can take many hours
> >
> > We do have KVM acceleration for x86 and arm FWIW which is probably
> > where we'd start testing this on the autobuilder.
> >
> > >    - With some physical target architectures it can take days (e.g. microblaze)
> > >
> > > The significantly increased execution speed of qemu-linux-user vs qemu system
> > > with glibc, and the ability for qemu-linux-user to be executed in parallel with
> > > the gcc test suite makes it a strong solution for continuous integration
> > > testing.
> >
> > Was that with or without KVM?
>
> Without KVM. I will add KVM testing with the system emulation tests I
> run, to get a better idea on exact performance differences.
>
> >
> > > The following table shows results for the major test suite components running
> > > with qemu-linux-user execution. The numbers represent 'failed tests'/'total
> > > tests'. The machines used to run the tests are the `qemu*` machine for the
> > > associated architecture, not all qemu machines available in oe-core were tested.
> > > It is important to note that these results are only indicative of
> > > qemu-linux-user behaviour and that there are a number of test failures that are
> > > due to issues not specific to qemu-linux-user.
> > >
> > >         | gcc          | g++          | libstdc++   | binutils    | gas         | ld          | glibc
> > > x86-64  |   589/135169 |   457/131913 |     1/13008 |     0/  236 |     0/ 1256 |   166/ 1975 |  1423/ 5991
> > > arm     |   469/123905 |   365/128416 |    19/12788 |     0/  191 |     0/  872 |   155/ 1479 |    64/ 5130
> > > aarch64 |   460/130904 |   364/128977 |     1/12789 |     0/  190 |     0/  442 |   157/ 1474 |    76/ 5882
> > > powerpc | 18336/116624 |  6747/128636 |    33/12996 |     0/  187 |     1/  265 |   157/ 1352 |  1218/ 5110
> > > mips64  |  1174/134744 |   401/130195 |    22/12780 |     0/  213 |    43/ 7245 |   803/ 1634 |  2032/ 5847
> > > riscv64 |   456/106399 |   376/128427 |     1/12748 |     0/  185 |     0/  257 |   152/ 1062 |    88/ 5847
> >
> > I'd be interested to know how these numbers compare to the ssh
> > execution...
>
> I will setup some OEQA automation to get results for this. It might
> take me a little bit since they can be slow to run.

Just an update here, managed to get the results for this. As you will
see below, running some of these tests is very slow on qemu system
emulation. Though kvm did give a decent boost in performance.

Note: qemuarm64 (sys) is missing gcc results because one of the gcc
tests crashes qemu.

                           | g++          | gcc          | glibc
| libatomic   | libgomp     | libitm      | libstdc++-v3
qemuarm (usr)              |   365/128416 |   469/123905 |    65/ 5130
|     0/   49 |     0/ 2515 |     0/   46 |     23/12782
qemuarm (sys)              |   365/128416 |   468/123874 |    47/ 5130
|     0/   49 |     0/ 2515 |    18/   46 |     48/12790
qemux86-64 (usr)           |   457/131913 |   589/135169 |  1423/ 5991
|     0/   54 |     0/ 2522 |     0/   46 |      1/13008
qemux86-64 (sys)           |   418/131913 |   519/135221 |  1418/ 5991
|     0/   54 |     1/ 2522 |    18/   46 |     51/13010
qemux86-64 (sys+kvm)       |   418/131913 |   519/135415 |    40/ 5991
|     0/   54 |     1/ 2522 |    18/   46 |     46/13010
qemuarm64 (usr)            |   364/128977 |   459/130904 |    75/ 5882
|     0/   54 |     0/ 2515 |     0/   46 |      1/12789
qemuarm64 (sys)            |   364/128977 |              |    43/ 5882
|     0/   54 |     0/ 2515 |    18/   46 |     62/12791
qemuppc (usr)              |  6747/128636 | 18336/116624 |  1220/ 5110
|     0/   49 |     2/ 2515 |     0/   46 |     33/12996
qemuppc (sys)              |   383/129056 |   800/119824 |  1188/ 5110
|     0/   49 |     2/ 2515 |    18/   46 |     34/12998
qemuriscv64 (usr)          |   376/128427 |   460/106399 |    86/ 5847
|     0/   54 |     4/ 2508 |             |      1/12748
qemuriscv64 (sys)          |   376/128427 |   458/106451 |    53/ 5847
|     0/   54 |     0/ 2508 |             |     52/12750
                           | g++          | gcc          | glibc
| libatomic   | libgomp     | libitm      | libstdc++-v3
qemuarm (usr)              |       9m 24s |       15m 3s |     37m 10s
|          8s |      6m 52s |          8s |       1h 24s
qemuarm (sys)              |   3h 58m 30s |  12h 21m 44s |  5h 36m 53s
|         55s |     45m 57s |         53s |  12h 16m 11s
qemux86-64 (usr)           |       8m 22s |      15m 48s |     36m 52s
|          8s |       6m 1s |          8s |      34m 42s
qemux86-64 (sys)           |   5h 38m 27s |  15h 15m 40s |  5h 54m 42s
|       1m 8s |     45m 52s |         55s |   3h 26m 11s
qemux86-64 (sys+kvm)       |      16m 22s |      56m 44s |  2h 29m 45s
|         25s |     16m 58s |         21s |      19m 20s
qemuarm64 (usr)            |       8m 34s |      16m 15s |     44m 25s
|          8s |      6m 23s |          8s |      35m 38s
qemuarm64 (sys)            |    4h 2m 53s |              |   6h 2m 39s
|       1m 7s |     44m 47s |         53s |    3h 9m 37s
qemuppc (usr)              |       6m 54s |      10m 47s |     32m 50s
|          6s |      6m 22s |          7s |      34m 25s
qemuppc (sys)              |   5h 46m 23s |  16h 16m 10s |   4h 10m 6s
|      1m 16s |   1h 3m 11s |      1m 12s |   4h 32m 45s
qemuriscv64 (usr)          |       6m 54s |      10m 23s |     36m 50s
|          7s |      9m 38s |             |      33m 13s
qemuriscv64 (sys)          |   2h 19m 24s |   6h 27m 37s |  4h 23m 43s
|         47s |     31m 47s |             |   1h 52m 18s

Regards,
Nathan


>
> >
> > The binutils results look good! :)
> >
> > > This patch also introduces some OEQA test cases which cover running the test
> > > suites. However in this specific patch it does not include any implementation
> > > for the automated setup of qemu system emulation testing with runqemu and NFS
> > > mounting for glibc tests. Also not included in these test cases is any known
> > > test failure filtering.
> >
> > The known test failure filtering is something we can use the OEQA
> > backend for, I'd envisage this being intergrated in a similar way to
> > the way we added ptest/ltp/ltp-posix there.
>
> I am not very familiar with the OEQA backend, and was not able to find
> anything about test filtering in lib/oeqa (just searching). Maybe I am
> looking in the wrong place, any pointers for where this part of the
> backend is located?
>
> Thanks,
> Nathan
>
>
>
> >
> > > I would also be interested in the opinion with regards to whether these test
> > > suites should be executed as part of the existing Yocto Autobuilder instance.
> >
> > Short answer is yes. We won't run them all the time but when it makes
> > sense and I'd happily see the autobuilder apart to be able to trigger
> > these appropriately. We can probably run the KVM accelerated arches
> > more often than the others.
> >
> > Plenty of implementation details to further discuss but this is great
> > to see!
> >
> > Cheers,
> >
> > Richard
> >


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-24 12:30     ` Nathan Rossi
@ 2019-07-24 13:55       ` richard.purdie
  2019-07-24 14:05         ` Mark Hatle
  0 siblings, 1 reply; 15+ messages in thread
From: richard.purdie @ 2019-07-24 13:55 UTC (permalink / raw)
  To: Nathan Rossi; +Cc: openembedded-core

On Wed, 2019-07-24 at 22:30 +1000, Nathan Rossi wrote:
> So I only hit one major issue with the oe-core qemu* machines I
> tested on when running under system emulation, specifically with
> aarch64/qemuarm64.
> 
> One (or more) test in the "c" suite of gcc causes qemu to crash due
> to what appears to be an internal qemu issue.
> 
> qemu outputted:
> qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion
> `s->gen_insn_end_off[num_insns] == off' failed.
> 
> The test that caused this was:
> gcc.target/aarch64/advsimd-intrinsics/vldX.c   -O2  execution test

Ok, interesting. I'd hope that issue could be resolved if it started
causing problems for us, or we could skip that test as a workaround I
guess.

> Just an update here, managed to get the results for this. As you will
> see below, running some of these tests is very slow on qemu system
> emulation. Though kvm did give a decent boost in performance.
> 
> Note: qemuarm64 (sys) is missing gcc results because one of the gcc
> tests crashes qemu.

The results were wrapped and hard to read so I unwrapped them (added
here for others):

                           | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
qemuarm (usr)              |   365/128416 |   469/123905 |    65/ 5130 |     0/   49 |     0/ 2515 |     0/   46 |     23/12782
qemuarm (sys)              |   365/128416 |   468/123874 |    47/ 5130 |     0/   49 |     0/ 2515 |    18/   46 |     48/12790
qemux86-64 (usr)           |   457/131913 |   589/135169 |  1423/ 5991 |     0/   54 |     0/ 2522 |     0/   46 |      1/13008
qemux86-64 (sys)           |   418/131913 |   519/135221 |  1418/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     51/13010
qemux86-64 (sys+kvm)       |   418/131913 |   519/135415 |    40/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     46/13010
qemuarm64 (usr)            |   364/128977 |   459/130904 |    75/ 5882 |     0/   54 |     0/ 2515 |     0/   46 |      1/12789
qemuarm64 (sys)            |   364/128977 |              |    43/ 5882 |     0/   54 |     0/ 2515 |    18/   46 |     62/12791
qemuppc (usr)              |  6747/128636 | 18336/116624 |  1220/ 5110 |     0/   49 |     2/ 2515 |     0/   46 |     33/12996
qemuppc (sys)              |   383/129056 |   800/119824 |  1188/ 5110 |     0/   49 |     2/ 2515 |    18/   46 |     34/12998
qemuriscv64 (usr)          |   376/128427 |   460/106399 |    86/ 5847 |     0/   54 |     4/ 2508 |             |      1/12748
qemuriscv64 (sys)          |   376/128427 |   458/106451 |    53/ 5847 |     0/   54 |     0/ 2508 |             |     52/12750

                           | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
qemuarm (usr)              |       9m 24s |       15m 3s |     37m 10s |          8s |      6m 52s |          8s |       1h 24s
qemuarm (sys)              |   3h 58m 30s |  12h 21m 44s |  5h 36m 53s |         55s |     45m 57s |         53s |  12h 16m 11s
qemux86-64 (usr)           |       8m 22s |      15m 48s |     36m 52s |          8s |       6m 1s |          8s |      34m 42s
qemux86-64 (sys)           |   5h 38m 27s |  15h 15m 40s |  5h 54m 42s |       1m 8s |     45m 52s |         55s |   3h 26m 11s
qemux86-64 (sys+kvm)       |      16m 22s |      56m 44s |  2h 29m 45s |         25s |     16m 58s |         21s |      19m 20s
qemuarm64 (usr)            |       8m 34s |      16m 15s |     44m 25s |          8s |      6m 23s |          8s |      35m 38s
qemuarm64 (sys)            |    4h 2m 53s |              |   6h 2m 39s |       1m 7s |     44m 47s |         53s |    3h 9m 37s
qemuppc (usr)              |       6m 54s |      10m 47s |     32m 50s |          6s |      6m 22s |          7s |      34m 25s
qemuppc (sys)              |   5h 46m 23s |  16h 16m 10s |   4h 10m 6s |      1m 16s |   1h 3m 11s |      1m 12s |   4h 32m 45s
qemuriscv64 (usr)          |       6m 54s |      10m 23s |     36m 50s |          7s |      9m 38s |             |      33m 13s
qemuriscv64 (sys)          |   2h 19m 24s |   6h 27m 37s |  4h 23m 43s |         47s |     31m 47s |             |   1h 52m 18s

This makes very interesting reading, thanks!

I'm quite amazed how much faster user mode qemu is at running the tests
against a system kvm qemu. The accuracy of sys, usr and sys+kvm looks
questionable in different places.

There isn't a clear answer here although its obvious qemuppc user mode
emulation is bad. The usermode testing is clearly the winner speed wise
by a long margin. I would like to understand why though as KVM should
be reasonable...

Cheers,

Richard







^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-24 13:55       ` richard.purdie
@ 2019-07-24 14:05         ` Mark Hatle
  2019-07-24 15:23           ` Nathan Rossi
  0 siblings, 1 reply; 15+ messages in thread
From: Mark Hatle @ 2019-07-24 14:05 UTC (permalink / raw)
  To: richard.purdie, Nathan Rossi; +Cc: openembedded-core

On 7/24/19 8:55 AM, richard.purdie@linuxfoundation.org wrote:
> On Wed, 2019-07-24 at 22:30 +1000, Nathan Rossi wrote:
>> So I only hit one major issue with the oe-core qemu* machines I
>> tested on when running under system emulation, specifically with
>> aarch64/qemuarm64.
>>
>> One (or more) test in the "c" suite of gcc causes qemu to crash due
>> to what appears to be an internal qemu issue.
>>
>> qemu outputted:
>> qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion
>> `s->gen_insn_end_off[num_insns] == off' failed.
>>
>> The test that caused this was:
>> gcc.target/aarch64/advsimd-intrinsics/vldX.c   -O2  execution test
> 
> Ok, interesting. I'd hope that issue could be resolved if it started
> causing problems for us, or we could skip that test as a workaround I
> guess.

When we have done similar testing like this, we have skipped these tests.  Much
of the time they are in corner case instructions and not something that really
gives relevant results.

But with that said, we should check if QEMU is already aware of this failure and
if not report it to them.

(The GNU tests also test various instructions that may not be available on all
processors, we've seen this many times on IA32 machines.  They just assume all
instructions are available, even if running on an older CPU.  So this is also
something to be aware of when interpreting the results. -- but QEMU shouldn't
crash!)

--Mark

>> Just an update here, managed to get the results for this. As you will
>> see below, running some of these tests is very slow on qemu system
>> emulation. Though kvm did give a decent boost in performance.
>>
>> Note: qemuarm64 (sys) is missing gcc results because one of the gcc
>> tests crashes qemu.
> 
> The results were wrapped and hard to read so I unwrapped them (added
> here for others):
> 
>                            | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
> qemuarm (usr)              |   365/128416 |   469/123905 |    65/ 5130 |     0/   49 |     0/ 2515 |     0/   46 |     23/12782
> qemuarm (sys)              |   365/128416 |   468/123874 |    47/ 5130 |     0/   49 |     0/ 2515 |    18/   46 |     48/12790
> qemux86-64 (usr)           |   457/131913 |   589/135169 |  1423/ 5991 |     0/   54 |     0/ 2522 |     0/   46 |      1/13008
> qemux86-64 (sys)           |   418/131913 |   519/135221 |  1418/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     51/13010
> qemux86-64 (sys+kvm)       |   418/131913 |   519/135415 |    40/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     46/13010
> qemuarm64 (usr)            |   364/128977 |   459/130904 |    75/ 5882 |     0/   54 |     0/ 2515 |     0/   46 |      1/12789
> qemuarm64 (sys)            |   364/128977 |              |    43/ 5882 |     0/   54 |     0/ 2515 |    18/   46 |     62/12791
> qemuppc (usr)              |  6747/128636 | 18336/116624 |  1220/ 5110 |     0/   49 |     2/ 2515 |     0/   46 |     33/12996
> qemuppc (sys)              |   383/129056 |   800/119824 |  1188/ 5110 |     0/   49 |     2/ 2515 |    18/   46 |     34/12998
> qemuriscv64 (usr)          |   376/128427 |   460/106399 |    86/ 5847 |     0/   54 |     4/ 2508 |             |      1/12748
> qemuriscv64 (sys)          |   376/128427 |   458/106451 |    53/ 5847 |     0/   54 |     0/ 2508 |             |     52/12750
> 
>                            | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
> qemuarm (usr)              |       9m 24s |       15m 3s |     37m 10s |          8s |      6m 52s |          8s |       1h 24s
> qemuarm (sys)              |   3h 58m 30s |  12h 21m 44s |  5h 36m 53s |         55s |     45m 57s |         53s |  12h 16m 11s
> qemux86-64 (usr)           |       8m 22s |      15m 48s |     36m 52s |          8s |       6m 1s |          8s |      34m 42s
> qemux86-64 (sys)           |   5h 38m 27s |  15h 15m 40s |  5h 54m 42s |       1m 8s |     45m 52s |         55s |   3h 26m 11s
> qemux86-64 (sys+kvm)       |      16m 22s |      56m 44s |  2h 29m 45s |         25s |     16m 58s |         21s |      19m 20s
> qemuarm64 (usr)            |       8m 34s |      16m 15s |     44m 25s |          8s |      6m 23s |          8s |      35m 38s
> qemuarm64 (sys)            |    4h 2m 53s |              |   6h 2m 39s |       1m 7s |     44m 47s |         53s |    3h 9m 37s
> qemuppc (usr)              |       6m 54s |      10m 47s |     32m 50s |          6s |      6m 22s |          7s |      34m 25s
> qemuppc (sys)              |   5h 46m 23s |  16h 16m 10s |   4h 10m 6s |      1m 16s |   1h 3m 11s |      1m 12s |   4h 32m 45s
> qemuriscv64 (usr)          |       6m 54s |      10m 23s |     36m 50s |          7s |      9m 38s |             |      33m 13s
> qemuriscv64 (sys)          |   2h 19m 24s |   6h 27m 37s |  4h 23m 43s |         47s |     31m 47s |             |   1h 52m 18s
> 
> This makes very interesting reading, thanks!
> 
> I'm quite amazed how much faster user mode qemu is at running the tests
> against a system kvm qemu. The accuracy of sys, usr and sys+kvm looks
> questionable in different places.
> 
> There isn't a clear answer here although its obvious qemuppc user mode
> emulation is bad. The usermode testing is clearly the winner speed wise
> by a long margin. I would like to understand why though as KVM should
> be reasonable...
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-24 14:05         ` Mark Hatle
@ 2019-07-24 15:23           ` Nathan Rossi
  2019-07-24 16:18             ` Alexander Kanavin
  0 siblings, 1 reply; 15+ messages in thread
From: Nathan Rossi @ 2019-07-24 15:23 UTC (permalink / raw)
  To: Mark Hatle, richard.purdie; +Cc: openembedded-core

On Thu, 25 Jul 2019 at 00:06, Mark Hatle <mark.hatle@windriver.com> wrote:
>
> On 7/24/19 8:55 AM, richard.purdie@linuxfoundation.org wrote:
> > On Wed, 2019-07-24 at 22:30 +1000, Nathan Rossi wrote:
> >> So I only hit one major issue with the oe-core qemu* machines I
> >> tested on when running under system emulation, specifically with
> >> aarch64/qemuarm64.
> >>
> >> One (or more) test in the "c" suite of gcc causes qemu to crash due
> >> to what appears to be an internal qemu issue.
> >>
> >> qemu outputted:
> >> qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion
> >> `s->gen_insn_end_off[num_insns] == off' failed.
> >>
> >> The test that caused this was:
> >> gcc.target/aarch64/advsimd-intrinsics/vldX.c   -O2  execution test
> >
> > Ok, interesting. I'd hope that issue could be resolved if it started
> > causing problems for us, or we could skip that test as a workaround I
> > guess.
>
> When we have done similar testing like this, we have skipped these tests.  Much
> of the time they are in corner case instructions and not something that really
> gives relevant results.
>
> But with that said, we should check if QEMU is already aware of this failure and
> if not report it to them.

Something I forgot to note was that this specific test runs fine under
qemu user.

>
> (The GNU tests also test various instructions that may not be available on all
> processors, we've seen this many times on IA32 machines.  They just assume all
> instructions are available, even if running on an older CPU.  So this is also
> something to be aware of when interpreting the results. -- but QEMU shouldn't
> crash!)

Yes this is something I noticed with -mhard-float/-msoft-float on arm.

>
> --Mark
>
> >> Just an update here, managed to get the results for this. As you will
> >> see below, running some of these tests is very slow on qemu system
> >> emulation. Though kvm did give a decent boost in performance.
> >>
> >> Note: qemuarm64 (sys) is missing gcc results because one of the gcc
> >> tests crashes qemu.
> >
> > The results were wrapped and hard to read so I unwrapped them (added
> > here for others):

Sorry about that.

> >
> >                            | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
> > qemuarm (usr)              |   365/128416 |   469/123905 |    65/ 5130 |     0/   49 |     0/ 2515 |     0/   46 |     23/12782
> > qemuarm (sys)              |   365/128416 |   468/123874 |    47/ 5130 |     0/   49 |     0/ 2515 |    18/   46 |     48/12790
> > qemux86-64 (usr)           |   457/131913 |   589/135169 |  1423/ 5991 |     0/   54 |     0/ 2522 |     0/   46 |      1/13008
> > qemux86-64 (sys)           |   418/131913 |   519/135221 |  1418/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     51/13010
> > qemux86-64 (sys+kvm)       |   418/131913 |   519/135415 |    40/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     46/13010
> > qemuarm64 (usr)            |   364/128977 |   459/130904 |    75/ 5882 |     0/   54 |     0/ 2515 |     0/   46 |      1/12789
> > qemuarm64 (sys)            |   364/128977 |              |    43/ 5882 |     0/   54 |     0/ 2515 |    18/   46 |     62/12791
> > qemuppc (usr)              |  6747/128636 | 18336/116624 |  1220/ 5110 |     0/   49 |     2/ 2515 |     0/   46 |     33/12996
> > qemuppc (sys)              |   383/129056 |   800/119824 |  1188/ 5110 |     0/   49 |     2/ 2515 |    18/   46 |     34/12998
> > qemuriscv64 (usr)          |   376/128427 |   460/106399 |    86/ 5847 |     0/   54 |     4/ 2508 |             |      1/12748
> > qemuriscv64 (sys)          |   376/128427 |   458/106451 |    53/ 5847 |     0/   54 |     0/ 2508 |             |     52/12750
> >
> >                            | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
> > qemuarm (usr)              |       9m 24s |       15m 3s |     37m 10s |          8s |      6m 52s |          8s |       1h 24s
> > qemuarm (sys)              |   3h 58m 30s |  12h 21m 44s |  5h 36m 53s |         55s |     45m 57s |         53s |  12h 16m 11s
> > qemux86-64 (usr)           |       8m 22s |      15m 48s |     36m 52s |          8s |       6m 1s |          8s |      34m 42s
> > qemux86-64 (sys)           |   5h 38m 27s |  15h 15m 40s |  5h 54m 42s |       1m 8s |     45m 52s |         55s |   3h 26m 11s
> > qemux86-64 (sys+kvm)       |      16m 22s |      56m 44s |  2h 29m 45s |         25s |     16m 58s |         21s |      19m 20s
> > qemuarm64 (usr)            |       8m 34s |      16m 15s |     44m 25s |          8s |      6m 23s |          8s |      35m 38s
> > qemuarm64 (sys)            |    4h 2m 53s |              |   6h 2m 39s |       1m 7s |     44m 47s |         53s |    3h 9m 37s
> > qemuppc (usr)              |       6m 54s |      10m 47s |     32m 50s |          6s |      6m 22s |          7s |      34m 25s
> > qemuppc (sys)              |   5h 46m 23s |  16h 16m 10s |   4h 10m 6s |      1m 16s |   1h 3m 11s |      1m 12s |   4h 32m 45s
> > qemuriscv64 (usr)          |       6m 54s |      10m 23s |     36m 50s |          7s |      9m 38s |             |      33m 13s
> > qemuriscv64 (sys)          |   2h 19m 24s |   6h 27m 37s |  4h 23m 43s |         47s |     31m 47s |             |   1h 52m 18s
> >
> > This makes very interesting reading, thanks!
> >
> > I'm quite amazed how much faster user mode qemu is at running the tests
> > against a system kvm qemu. The accuracy of sys, usr and sys+kvm looks
> > questionable in different places.

The speed user mode qemu gets comes from multi-threaded execution.
Whilst kvm gets better single threaded execution performance over user
mode qemu, more threads of tests can run with user mode. I probably
should have mentioned all the above runs were on an 8 thread system.
So on a bigger build machine user mode qemu probably gets even better
scaling.

> >
> > There isn't a clear answer here although its obvious qemuppc user mode
> > emulation is bad. The usermode testing is clearly the winner speed wise
> > by a long margin. I would like to understand why though as KVM should
> > be reasonable...

Just given some inspection of the systems and host while running, it
appears that two of the major performances hits were the overheads in
SSH (e.g. encryption, etc) and the use of multiple threads trying to
run things on the single core target.

I will look into the test failures with user mode and try to resolve
some of them. If its possible to have similar results between usr/sys
then it would help make the choice between them a lot easier.
Resolving some of the test failures should also help to bring the
results in line with expectation.

Regards,
Nathan

> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >
> >
>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-24 15:23           ` Nathan Rossi
@ 2019-07-24 16:18             ` Alexander Kanavin
  2019-08-12  6:41               ` Nathan Rossi
  0 siblings, 1 reply; 15+ messages in thread
From: Alexander Kanavin @ 2019-07-24 16:18 UTC (permalink / raw)
  To: Nathan Rossi; +Cc: openembedded-core

Does the speed improve if system Qemu is configured to use several cpu cores (I think this doesn’t happen by default in yocto)?

Alex

> On 24 Jul 2019, at 18.23, Nathan Rossi <nathan@nathanrossi.com> wrote:
> 
>> On Thu, 25 Jul 2019 at 00:06, Mark Hatle <mark.hatle@windriver.com> wrote:
>> 
>>> On 7/24/19 8:55 AM, richard.purdie@linuxfoundation.org wrote:
>>>> On Wed, 2019-07-24 at 22:30 +1000, Nathan Rossi wrote:
>>>> So I only hit one major issue with the oe-core qemu* machines I
>>>> tested on when running under system emulation, specifically with
>>>> aarch64/qemuarm64.
>>>> 
>>>> One (or more) test in the "c" suite of gcc causes qemu to crash due
>>>> to what appears to be an internal qemu issue.
>>>> 
>>>> qemu outputted:
>>>> qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion
>>>> `s->gen_insn_end_off[num_insns] == off' failed.
>>>> 
>>>> The test that caused this was:
>>>> gcc.target/aarch64/advsimd-intrinsics/vldX.c   -O2  execution test
>>> 
>>> Ok, interesting. I'd hope that issue could be resolved if it started
>>> causing problems for us, or we could skip that test as a workaround I
>>> guess.
>> 
>> When we have done similar testing like this, we have skipped these tests.  Much
>> of the time they are in corner case instructions and not something that really
>> gives relevant results.
>> 
>> But with that said, we should check if QEMU is already aware of this failure and
>> if not report it to them.
> 
> Something I forgot to note was that this specific test runs fine under
> qemu user.
> 
>> 
>> (The GNU tests also test various instructions that may not be available on all
>> processors, we've seen this many times on IA32 machines.  They just assume all
>> instructions are available, even if running on an older CPU.  So this is also
>> something to be aware of when interpreting the results. -- but QEMU shouldn't
>> crash!)
> 
> Yes this is something I noticed with -mhard-float/-msoft-float on arm.
> 
>> 
>> --Mark
>> 
>>>> Just an update here, managed to get the results for this. As you will
>>>> see below, running some of these tests is very slow on qemu system
>>>> emulation. Though kvm did give a decent boost in performance.
>>>> 
>>>> Note: qemuarm64 (sys) is missing gcc results because one of the gcc
>>>> tests crashes qemu.
>>> 
>>> The results were wrapped and hard to read so I unwrapped them (added
>>> here for others):
> 
> Sorry about that.
> 
>>> 
>>>                           | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
>>> qemuarm (usr)              |   365/128416 |   469/123905 |    65/ 5130 |     0/   49 |     0/ 2515 |     0/   46 |     23/12782
>>> qemuarm (sys)              |   365/128416 |   468/123874 |    47/ 5130 |     0/   49 |     0/ 2515 |    18/   46 |     48/12790
>>> qemux86-64 (usr)           |   457/131913 |   589/135169 |  1423/ 5991 |     0/   54 |     0/ 2522 |     0/   46 |      1/13008
>>> qemux86-64 (sys)           |   418/131913 |   519/135221 |  1418/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     51/13010
>>> qemux86-64 (sys+kvm)       |   418/131913 |   519/135415 |    40/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     46/13010
>>> qemuarm64 (usr)            |   364/128977 |   459/130904 |    75/ 5882 |     0/   54 |     0/ 2515 |     0/   46 |      1/12789
>>> qemuarm64 (sys)            |   364/128977 |              |    43/ 5882 |     0/   54 |     0/ 2515 |    18/   46 |     62/12791
>>> qemuppc (usr)              |  6747/128636 | 18336/116624 |  1220/ 5110 |     0/   49 |     2/ 2515 |     0/   46 |     33/12996
>>> qemuppc (sys)              |   383/129056 |   800/119824 |  1188/ 5110 |     0/   49 |     2/ 2515 |    18/   46 |     34/12998
>>> qemuriscv64 (usr)          |   376/128427 |   460/106399 |    86/ 5847 |     0/   54 |     4/ 2508 |             |      1/12748
>>> qemuriscv64 (sys)          |   376/128427 |   458/106451 |    53/ 5847 |     0/   54 |     0/ 2508 |             |     52/12750
>>> 
>>>                           | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
>>> qemuarm (usr)              |       9m 24s |       15m 3s |     37m 10s |          8s |      6m 52s |          8s |       1h 24s
>>> qemuarm (sys)              |   3h 58m 30s |  12h 21m 44s |  5h 36m 53s |         55s |     45m 57s |         53s |  12h 16m 11s
>>> qemux86-64 (usr)           |       8m 22s |      15m 48s |     36m 52s |          8s |       6m 1s |          8s |      34m 42s
>>> qemux86-64 (sys)           |   5h 38m 27s |  15h 15m 40s |  5h 54m 42s |       1m 8s |     45m 52s |         55s |   3h 26m 11s
>>> qemux86-64 (sys+kvm)       |      16m 22s |      56m 44s |  2h 29m 45s |         25s |     16m 58s |         21s |      19m 20s
>>> qemuarm64 (usr)            |       8m 34s |      16m 15s |     44m 25s |          8s |      6m 23s |          8s |      35m 38s
>>> qemuarm64 (sys)            |    4h 2m 53s |              |   6h 2m 39s |       1m 7s |     44m 47s |         53s |    3h 9m 37s
>>> qemuppc (usr)              |       6m 54s |      10m 47s |     32m 50s |          6s |      6m 22s |          7s |      34m 25s
>>> qemuppc (sys)              |   5h 46m 23s |  16h 16m 10s |   4h 10m 6s |      1m 16s |   1h 3m 11s |      1m 12s |   4h 32m 45s
>>> qemuriscv64 (usr)          |       6m 54s |      10m 23s |     36m 50s |          7s |      9m 38s |             |      33m 13s
>>> qemuriscv64 (sys)          |   2h 19m 24s |   6h 27m 37s |  4h 23m 43s |         47s |     31m 47s |             |   1h 52m 18s
>>> 
>>> This makes very interesting reading, thanks!
>>> 
>>> I'm quite amazed how much faster user mode qemu is at running the tests
>>> against a system kvm qemu. The accuracy of sys, usr and sys+kvm looks
>>> questionable in different places.
> 
> The speed user mode qemu gets comes from multi-threaded execution.
> Whilst kvm gets better single threaded execution performance over user
> mode qemu, more threads of tests can run with user mode. I probably
> should have mentioned all the above runs were on an 8 thread system.
> So on a bigger build machine user mode qemu probably gets even better
> scaling.
> 
>>> 
>>> There isn't a clear answer here although its obvious qemuppc user mode
>>> emulation is bad. The usermode testing is clearly the winner speed wise
>>> by a long margin. I would like to understand why though as KVM should
>>> be reasonable...
> 
> Just given some inspection of the systems and host while running, it
> appears that two of the major performances hits were the overheads in
> SSH (e.g. encryption, etc) and the use of multiple threads trying to
> run things on the single core target.
> 
> I will look into the test failures with user mode and try to resolve
> some of them. If its possible to have similar results between usr/sys
> then it would help make the choice between them a lot easier.
> Resolving some of the test failures should also help to bring the
> results in line with expectation.
> 
> Regards,
> Nathan
> 
>>> 
>>> Cheers,
>>> 
>>> Richard
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC PATCH] Add gnu testsuite execution for OEQA
  2019-07-24 16:18             ` Alexander Kanavin
@ 2019-08-12  6:41               ` Nathan Rossi
  0 siblings, 0 replies; 15+ messages in thread
From: Nathan Rossi @ 2019-08-12  6:41 UTC (permalink / raw)
  To: Alexander Kanavin; +Cc: openembedded-core

On Thu, 25 Jul 2019 at 02:19, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> Does the speed improve if system Qemu is configured to use several cpu cores (I think this doesn’t happen by default in yocto)?

Sorry for the delayed response. I had tested this initially and did
not see any decent scaling but wanted to test it more.

After some further testing and inspection, it still does not scale as
one might expect. Moving from 1 core to 2 provided a small performance
boost, but scaling up to 4 or 8 cores provided very little gain.
Looking at what the host is doing occasionally showed that rngd was
using 125% CPU, but since sshd is supposed to be using /dev/urandom I
am not sure what is limiting the performance.

Regards,
Nathan


>
> Alex
>
> > On 24 Jul 2019, at 18.23, Nathan Rossi <nathan@nathanrossi.com> wrote:
> >
> >> On Thu, 25 Jul 2019 at 00:06, Mark Hatle <mark.hatle@windriver.com> wrote:
> >>
> >>> On 7/24/19 8:55 AM, richard.purdie@linuxfoundation.org wrote:
> >>>> On Wed, 2019-07-24 at 22:30 +1000, Nathan Rossi wrote:
> >>>> So I only hit one major issue with the oe-core qemu* machines I
> >>>> tested on when running under system emulation, specifically with
> >>>> aarch64/qemuarm64.
> >>>>
> >>>> One (or more) test in the "c" suite of gcc causes qemu to crash due
> >>>> to what appears to be an internal qemu issue.
> >>>>
> >>>> qemu outputted:
> >>>> qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion
> >>>> `s->gen_insn_end_off[num_insns] == off' failed.
> >>>>
> >>>> The test that caused this was:
> >>>> gcc.target/aarch64/advsimd-intrinsics/vldX.c   -O2  execution test
> >>>
> >>> Ok, interesting. I'd hope that issue could be resolved if it started
> >>> causing problems for us, or we could skip that test as a workaround I
> >>> guess.
> >>
> >> When we have done similar testing like this, we have skipped these tests.  Much
> >> of the time they are in corner case instructions and not something that really
> >> gives relevant results.
> >>
> >> But with that said, we should check if QEMU is already aware of this failure and
> >> if not report it to them.
> >
> > Something I forgot to note was that this specific test runs fine under
> > qemu user.
> >
> >>
> >> (The GNU tests also test various instructions that may not be available on all
> >> processors, we've seen this many times on IA32 machines.  They just assume all
> >> instructions are available, even if running on an older CPU.  So this is also
> >> something to be aware of when interpreting the results. -- but QEMU shouldn't
> >> crash!)
> >
> > Yes this is something I noticed with -mhard-float/-msoft-float on arm.
> >
> >>
> >> --Mark
> >>
> >>>> Just an update here, managed to get the results for this. As you will
> >>>> see below, running some of these tests is very slow on qemu system
> >>>> emulation. Though kvm did give a decent boost in performance.
> >>>>
> >>>> Note: qemuarm64 (sys) is missing gcc results because one of the gcc
> >>>> tests crashes qemu.
> >>>
> >>> The results were wrapped and hard to read so I unwrapped them (added
> >>> here for others):
> >
> > Sorry about that.
> >
> >>>
> >>>                           | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
> >>> qemuarm (usr)              |   365/128416 |   469/123905 |    65/ 5130 |     0/   49 |     0/ 2515 |     0/   46 |     23/12782
> >>> qemuarm (sys)              |   365/128416 |   468/123874 |    47/ 5130 |     0/   49 |     0/ 2515 |    18/   46 |     48/12790
> >>> qemux86-64 (usr)           |   457/131913 |   589/135169 |  1423/ 5991 |     0/   54 |     0/ 2522 |     0/   46 |      1/13008
> >>> qemux86-64 (sys)           |   418/131913 |   519/135221 |  1418/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     51/13010
> >>> qemux86-64 (sys+kvm)       |   418/131913 |   519/135415 |    40/ 5991 |     0/   54 |     1/ 2522 |    18/   46 |     46/13010
> >>> qemuarm64 (usr)            |   364/128977 |   459/130904 |    75/ 5882 |     0/   54 |     0/ 2515 |     0/   46 |      1/12789
> >>> qemuarm64 (sys)            |   364/128977 |              |    43/ 5882 |     0/   54 |     0/ 2515 |    18/   46 |     62/12791
> >>> qemuppc (usr)              |  6747/128636 | 18336/116624 |  1220/ 5110 |     0/   49 |     2/ 2515 |     0/   46 |     33/12996
> >>> qemuppc (sys)              |   383/129056 |   800/119824 |  1188/ 5110 |     0/   49 |     2/ 2515 |    18/   46 |     34/12998
> >>> qemuriscv64 (usr)          |   376/128427 |   460/106399 |    86/ 5847 |     0/   54 |     4/ 2508 |             |      1/12748
> >>> qemuriscv64 (sys)          |   376/128427 |   458/106451 |    53/ 5847 |     0/   54 |     0/ 2508 |             |     52/12750
> >>>
> >>>                           | g++          | gcc          | glibc       | libatomic   | libgomp     | libitm      | libstdc++-v3
> >>> qemuarm (usr)              |       9m 24s |       15m 3s |     37m 10s |          8s |      6m 52s |          8s |       1h 24s
> >>> qemuarm (sys)              |   3h 58m 30s |  12h 21m 44s |  5h 36m 53s |         55s |     45m 57s |         53s |  12h 16m 11s
> >>> qemux86-64 (usr)           |       8m 22s |      15m 48s |     36m 52s |          8s |       6m 1s |          8s |      34m 42s
> >>> qemux86-64 (sys)           |   5h 38m 27s |  15h 15m 40s |  5h 54m 42s |       1m 8s |     45m 52s |         55s |   3h 26m 11s
> >>> qemux86-64 (sys+kvm)       |      16m 22s |      56m 44s |  2h 29m 45s |         25s |     16m 58s |         21s |      19m 20s
> >>> qemuarm64 (usr)            |       8m 34s |      16m 15s |     44m 25s |          8s |      6m 23s |          8s |      35m 38s
> >>> qemuarm64 (sys)            |    4h 2m 53s |              |   6h 2m 39s |       1m 7s |     44m 47s |         53s |    3h 9m 37s
> >>> qemuppc (usr)              |       6m 54s |      10m 47s |     32m 50s |          6s |      6m 22s |          7s |      34m 25s
> >>> qemuppc (sys)              |   5h 46m 23s |  16h 16m 10s |   4h 10m 6s |      1m 16s |   1h 3m 11s |      1m 12s |   4h 32m 45s
> >>> qemuriscv64 (usr)          |       6m 54s |      10m 23s |     36m 50s |          7s |      9m 38s |             |      33m 13s
> >>> qemuriscv64 (sys)          |   2h 19m 24s |   6h 27m 37s |  4h 23m 43s |         47s |     31m 47s |             |   1h 52m 18s
> >>>
> >>> This makes very interesting reading, thanks!
> >>>
> >>> I'm quite amazed how much faster user mode qemu is at running the tests
> >>> against a system kvm qemu. The accuracy of sys, usr and sys+kvm looks
> >>> questionable in different places.
> >
> > The speed user mode qemu gets comes from multi-threaded execution.
> > Whilst kvm gets better single threaded execution performance over user
> > mode qemu, more threads of tests can run with user mode. I probably
> > should have mentioned all the above runs were on an 8 thread system.
> > So on a bigger build machine user mode qemu probably gets even better
> > scaling.
> >
> >>>
> >>> There isn't a clear answer here although its obvious qemuppc user mode
> >>> emulation is bad. The usermode testing is clearly the winner speed wise
> >>> by a long margin. I would like to understand why though as KVM should
> >>> be reasonable...
> >
> > Just given some inspection of the systems and host while running, it
> > appears that two of the major performances hits were the overheads in
> > SSH (e.g. encryption, etc) and the use of multiple threads trying to
> > run things on the single core target.
> >
> > I will look into the test failures with user mode and try to resolve
> > some of them. If its possible to have similar results between usr/sys
> > then it would help make the choice between them a lot easier.
> > Resolving some of the test failures should also help to bring the
> > results in line with expectation.
> >
> > Regards,
> > Nathan
> >
> >>>
> >>> Cheers,
> >>>
> >>> Richard
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2019-08-12  6:41 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-06 11:39 [RFC PATCH] Add gnu testsuite execution for OEQA Nathan Rossi
2019-07-06 12:52 ` Richard Purdie
2019-07-08 20:55   ` Alejandro Enedino Hernandez Samaniego
2019-07-09 10:59     ` Nathan Rossi
2019-07-09 10:43   ` Nathan Rossi
2019-07-24 12:30     ` Nathan Rossi
2019-07-24 13:55       ` richard.purdie
2019-07-24 14:05         ` Mark Hatle
2019-07-24 15:23           ` Nathan Rossi
2019-07-24 16:18             ` Alexander Kanavin
2019-08-12  6:41               ` Nathan Rossi
2019-07-09 11:16 ` Burton, Ross
2019-07-09 11:47   ` Nathan Rossi
2019-07-09 11:54     ` Burton, Ross
2019-07-09 20:12     ` Khem Raj

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.