From: jepler <jepler@unpythonic.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1585840] Re: multiprocess program gets incorrect results with qemu arm-linux-user
Date: Tue, 07 Nov 2017 14:45:05 -0000 [thread overview]
Message-ID: <151006590603.4122.9423726872402533995.malone@gac.canonical.com> (raw)
In-Reply-To: 20160526014921.26209.46866.malonedeb@chaenomeles.canonical.com
I agree. The test program I originally attached works (completes in way under 1 second) on
debian wheezy
x86_64
i7-4930K
and doesn't work on
debian stretch
x86_64
i7-4790K
The test program should run in well under 1s, even under qemu-user-arm.
The problem with my test program seems to be in the initial
synchronization, which is janky because my standalone test program isn't
using a proper synchronization primitive to make sure the two threads
start incrementing the shared counter at around the same time. I've
attached an updated version which works for me on wheezy x86_64, stretch
x86_64, trusty armhf, but not on stretch x86-64 + qemu-user.
Typical output:
$ ./a.out process
multiprocess test
starting is_primary=0
starting is_primary=1
at end, *mem = 2000000
at end, *mem = 2000000
should be 2000000
should be 2000000
Typical failing output under qemu-arm-static:
$ qemu-arm-static ./a.arm process
multiprocess test
starting is_primary=0
starting is_primary=1
at end, *mem = 1010975
at end, *mem = 1010975
should be 2000000
should be 2000000
Note that when qemu-arm-static is restricted to 1 CPU via `tasket`, the
frequency of the failure changes from "almost every time" to "one in
ten".
Thank you for taking the time to look at my test program. I apologize
that I caused you to waste a day of (CPU) time waiting for the test
program to complete.
** Attachment added: "Updated test program"
https://bugs.launchpad.net/qemu/+bug/1585840/+attachment/5005420/+files/shmipc.c
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1585840
Title:
multiprocess program gets incorrect results with qemu arm-linux-user
Status in QEMU:
Incomplete
Bug description:
The attached program can run either in a threaded mode or a
multiprocess mode. It defaults to threaded mode, and switches to
multiprocess mode if the first positional argument is "process".
"success" of the test is defined as the final count being seen as
2000000 by both tasks.
In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf
userspace (4 cores), the test program consistently completes
successfully in both modes. But with qemu arm-linux-user, the test
consistently succeeds in threaded mode and generally fails in
multiprocess mode.
The test reflects an essential aspect of how the Free and Open Source
project linuxcnc's IPC system works: shared memory regions (created by
shmat, but mmap would probably behave the same) contain data and
mutexes. I observed that our testsuite encounters numerous deadlocks
and failures when running in an schroot with qemu-user (x86_64 host),
and I believe the underlying cause is improper support for atomic
operations in a multiprocess model. (the testsuite consistently passes
on real hardware)
I observed the same failure at v1.6.0 and master
(v2.6.0-424-g287db79), as well as in the outdated Debian version
1:2.1+dfsg-12+deb8u5a.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1585840/+subscriptions
next prev parent reply other threads:[~2017-11-07 15:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160526014921.26209.46866.malonedeb@chaenomeles.canonical.com>
2017-11-06 19:35 ` [Qemu-devel] [Bug 1585840] Re: multiprocess program gets incorrect results with qemu arm-linux-user Peter Maydell
2017-11-07 11:05 ` Peter Maydell
2017-11-07 14:45 ` jepler [this message]
2017-11-07 14:46 ` jepler
2017-11-07 16:01 ` Peter Maydell
2021-05-04 7:23 ` Thomas Huth
2021-06-23 17:32 ` Richard Henderson
2021-08-25 7:25 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=151006590603.4122.9423726872402533995.malone@gac.canonical.com \
--to=jepler@unpythonic.net \
--cc=1585840@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).