qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v3 19/19] test-bdrv-drain: Test dra


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v3 19/19] test-bdrv-drain: Test draining job source child and parent
Date: Fri, 21 Sep 2018 12:01:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 9/20/18 11:19 AM, Kevin Wolf wrote:
For the block job drain test, don't only test draining the source and
the target node, but create a backing chain for the source
(source_backing <- source <- source_overlay) and test draining each of
the nodes in it.

When using iothreads, the source node (and therefore the job) is in a
different AioContext than the drain, which happens from the main
thread. This way, the main thread waits in AIO_WAIT_WHILE() for the
iothread to make process and aio_wait_kick() is required to notify it.
The test validates that calling bdrv_wakeup() for a child or a parent
node will actually notify AIO_WAIT_WHILE() instead of letting it hang.

Signed-off-by: Kevin Wolf <address@hidden>
---
  tests/test-bdrv-drain.c | 75 +++++++++++++++++++++++++++++++++++++++++++------
  1 file changed, 67 insertions(+), 8 deletions(-)


@@ -818,12 +819,17 @@ static int coroutine_fn test_job_run(Job *job, Error 
**errp)
  {
      TestBlockJob *s = container_of(job, TestBlockJob, common.job);
+ /* We are running the actual job code past the pause point in
+     * job_co_entry(). */
+    s->running = true;
+
      job_transition_to_ready(&s->common.job);
      while (!s->should_complete) {
          /* Avoid job_sleep_ns() because it marks the job as !busy. We want to
           * emulate some actual activity (probably some I/O) here so that drain
           * has to wait for this acitivity to stop. */
-        qemu_co_sleep_ns(QEMU_CLOCK_REALTIME, 100000);
+        qemu_co_sleep_ns(QEMU_CLOCK_REALTIME, 1000000);

The commit message didn't mention why you had to lengthen this sleep, but I'm guessing it's because you are now doing enough additional things that you have to scale the delay to match?

Reviewed-by: Eric Blake <address@hidden>

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]