qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Thomas Huth" <th.huth@posteo.de>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Michael Tokarev" <mjt@tls.msk.ru>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Reinoud Zandijk" <reinoud@netbsd.org>,
	"Ryo ONODERA" <ryoon@netbsd.org>,
	"Brad Smith" <brad@comstyle.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: QEMU's tests/unit/test-iov times out on NetBSD and OpenBSD
Date: Fri, 19 Jan 2024 17:33:51 +0000	[thread overview]
Message-ID: <Zaqyf95_NzOlcVwc@redhat.com> (raw)
In-Reply-To: <b851a8f8-228f-45db-a636-5321f6a41f1e@redhat.com>

On Fri, Jan 19, 2024 at 05:13:25PM +0100, Thomas Huth wrote:
> On 19/01/2024 17.07, Daniel P. Berrangé wrote:
> > On Fri, Jan 19, 2024 at 03:55:49PM +0000, Thomas Huth wrote:
> > > 
> > >   Hi,
> > > 
> > > since we recently introduced test timouts in QEMU's meson set up, I noticed
> > > that the tests/unit/test-iov times out when doing "make vm-build-netbsd
> > > BUILD_TARGET=check-unit" (or vm-build-openbsd).
> > > 
> > > And indeed, when increasing the timeout, you can see that the test-iov runs
> > > for multiple minutes on these BSDs while it finishes within few seconds on
> > > Linux.
> > > 
> > > I had a closer look at the test, and the problem seems to be the
> > > 
> > >   usleep(g_test_rand_int_range(0, 30));
> > > 
> > > in the test_io() function. If I get that right, the usleep() seems to be
> > > more or less precise on (modern) Linux, but it seems like it sleeps for
> > > multiple milliseconds (not microseconds) on the BSDs. Since it is used in a
> > > nested loop, these milliseconds add up to a long time in total during the
> > > test.
> > > 
> > > Does anybody have an idea how to fix that? Is there a more precise (but stil
> > > portable) way to sleep less long here? Or could we maybe remove the usleep()
> > > here completely (it does not seem to have a real benefit for testing as far
> > > as I can see)?
> > 
> > 'g_usleep' has the same API contract, but is implemented in terms
> > of 'nanosleep' on *NIX. So as a quick test, try switching usleep
> > to g_usleep and see if we get lucky.
> 
> No, that seems to behave the same way, unfortunately.
> 
> Do you see a reason why we'd really need the usleep() here at all?
> Otherwise, I think I'll send a patch to simply remove it...

We're looping on iov_send() on a non-blocking socket.

In the EAGAIN scenario we select() to wait for writability which is
good.

In the scenario where we wrote at least 1 byte, however, we have
the usleep(). Presumably the idea is that we should not immediately
try iov_send again as it might not be ready to send more data. This
should only be needed, however, if there is still more data waiting
to be sent and we should select() instead anyway. So I think this:

               do {
                   s = g_test_rand_int_range(0, j - k + 1);
                   r = iov_send(sv[1], iov, niov, k, s);
                   g_assert(memcmp(iov, siov, sizeof(*iov)*niov) == 0);
                   if (r >= 0) {
                       k += r;
                       usleep(g_test_rand_int_range(0, 30));
                   } else if (errno == EAGAIN) {
                       select(sv[1]+1, NULL, &fds, NULL, NULL);
                       continue;
                   } else {
                       perror("send");
                       exit(1);
                   }
               } while(k < j);

should change to:


               do {
                   s = g_test_rand_int_range(0, j - k + 1);
                   r = iov_send(sv[1], iov, niov, k, s);
                   g_assert(memcmp(iov, siov, sizeof(*iov)*niov) == 0);
		   if (r == -1 && errno == EAGAIN) {
		       r = 0;
		   }
                   if (r >= 0)
                       k += r;
		       if (k < j) {
                         select(sv[1]+1, NULL, &fds, NULL, NULL);
                         continue;
		       }
                   } else {
                       perror("send");
                       exit(1);
                   }
               } while(k < j);


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



      reply	other threads:[~2024-01-19 17:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 15:55 QEMU's tests/unit/test-iov times out on NetBSD and OpenBSD Thomas Huth
2024-01-19 16:07 ` Daniel P. Berrangé
2024-01-19 16:13   ` Thomas Huth
2024-01-19 17:33     ` Daniel P. Berrangé [this message]

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=Zaqyf95_NzOlcVwc@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=brad@comstyle.com \
    --cc=f4bug@amsat.org \
    --cc=mjt@tls.msk.ru \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=reinoud@netbsd.org \
    --cc=ryoon@netbsd.org \
    --cc=th.huth@posteo.de \
    --cc=thuth@redhat.com \
    /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).