From: Fam Zheng <fam@euphon.net>
To: Zhenyu Ye <yezhenyu2@huawei.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, armbru@redhat.com, xiexiangyou@huawei.com,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
pbonzini@redhat.com, mreitz@redhat.com
Subject: Re: [PATCH v1 0/2] Add timeout mechanism to qmp actions
Date: Fri, 18 Sep 2020 14:06:28 +0000 [thread overview]
Message-ID: <20200918140628.GA2509473@dev> (raw)
In-Reply-To: <5a5822ec-f3bc-a247-2b5a-f764b941c820@huawei.com>
On 2020-09-18 19:23, Zhenyu Ye wrote:
> Thread 5 (LWP 4802):
> #0 0x0000ffff83086b54 in syscall () at /lib64/libc.so.6
> #1 0x0000ffff834598b8 in io_submit () at /lib64/libaio.so.1
> #2 0x0000aaaae851e89c in ioq_submit (s=0xfffd3c001bb0) at ../block/linux-aio.c:299
> #3 0x0000aaaae851eb50 in laio_io_unplug (bs=0xaaaaef0f2340, s=0xfffd3c001bb0)
> at ../block/linux-aio.c:344
> #4 0x0000aaaae8559f1c in raw_aio_unplug (bs=0xaaaaef0f2340) at ../block/file-posix.c:2063
> #5 0x0000aaaae8538344 in bdrv_io_unplug (bs=0xaaaaef0f2340) at ../block/io.c:3135
> #6 0x0000aaaae8538360 in bdrv_io_unplug (bs=0xaaaaef0eb020) at ../block/io.c:3140
> #7 0x0000aaaae8496104 in blk_io_unplug (blk=0xaaaaef0e8f20)
> at ../block/block-backend.c:2147
> #8 0x0000aaaae830e1a4 in virtio_blk_handle_vq (s=0xaaaaf0374280, vq=0xffff700fc1d8)
> at ../hw/block/virtio-blk.c:796
> #9 0x0000aaaae82e6b68 in virtio_blk_data_plane_handle_output
> (vdev=0xaaaaf0374280, vq=0xffff700fc1d8) at ../hw/block/dataplane/virtio-blk.c:165
> #10 0x0000aaaae83878fc in virtio_queue_notify_aio_vq (vq=0xffff700fc1d8)
> at ../hw/virtio/virtio.c:2325
> #11 0x0000aaaae838ab50 in virtio_queue_host_notifier_aio_poll (opaque=0xffff700fc250)
> at ../hw/virtio/virtio.c:3545
> #12 0x0000aaaae85fab3c in run_poll_handlers_once
> (ctx=0xaaaaef0a87b0, now=77604310618960, timeout=0xffff73ffdf78)
> at ../util/aio-posix.c:398
> #13 0x0000aaaae85fae5c in run_poll_handlers
> (ctx=0xaaaaef0a87b0, max_ns=4000, timeout=0xffff73ffdf78) at ../util/aio-posix.c:492
> #14 0x0000aaaae85fb078 in try_poll_mode (ctx=0xaaaaef0a87b0, timeout=0xffff73ffdf78)
> at ../util/aio-posix.c:535
> #15 0x0000aaaae85fb180 in aio_poll (ctx=0xaaaaef0a87b0, blocking=true)
> at ../util/aio-posix.c:571
> #16 0x0000aaaae8027004 in iothread_run (opaque=0xaaaaeee79a00) at ../iothread.c:73
> #17 0x0000aaaae85f269c in qemu_thread_start (args=0xaaaaef0a8d10)
> at ../util/qemu-thread-posix.c:521
> #18 0x0000ffff831428bc in () at /lib64/libpthread.so.0
> #19 0x0000ffff8308aa1c in () at /lib64/libc.so.6
I can see how blocking in a slow io_submit can cause trouble for main
thread. I think one way to fix it (until it's made truly async in new
kernels) is moving the io_submit call to thread pool, and wrapped in a
coroutine, perhaps.
I'm not sure qmp timeout is a complete solution because we would still
suffer from a blocked state for a period, in this exact situation before
the timeout.
Fam
next prev parent reply other threads:[~2020-09-18 14:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 14:52 [PATCH v1 0/2] Add timeout mechanism to qmp actions Zhenyu Ye
2020-08-10 14:52 ` [PATCH v1 1/2] util: introduce aio_context_acquire_timeout Zhenyu Ye
2020-08-10 14:52 ` [PATCH v1 2/2] qmp: use aio_context_acquire_timeout replace aio_context_acquire Zhenyu Ye
2020-08-10 15:38 ` [PATCH v1 0/2] Add timeout mechanism to qmp actions Kevin Wolf
2020-08-11 13:54 ` Zhenyu Ye
2020-08-21 12:52 ` Stefan Hajnoczi
2020-09-14 13:27 ` Stefan Hajnoczi
2020-09-17 7:36 ` Zhenyu Ye
2020-09-17 10:10 ` Fam Zheng
2020-09-17 15:44 ` Stefan Hajnoczi
2020-09-17 16:01 ` Fam Zheng
2020-09-18 11:23 ` Zhenyu Ye
2020-09-18 14:06 ` Fam Zheng [this message]
2020-09-19 2:22 ` Zhenyu Ye
2020-09-21 11:14 ` Fam Zheng
2020-10-13 10:00 ` Stefan Hajnoczi
2020-10-19 12:40 ` Zhenyu Ye
2020-10-19 13:25 ` Paolo Bonzini
2020-10-20 1:34 ` Zhenyu Ye
2020-10-22 16:29 ` Fam Zheng
2020-12-08 13:10 ` Stefan Hajnoczi
2020-12-08 13:47 ` Glauber Costa
2020-12-14 16:33 ` Stefan Hajnoczi
2020-12-21 11:30 ` Zhenyu Ye
2020-09-14 14:42 ` Daniel P. Berrangé
2020-09-17 8:12 ` Zhenyu Ye
2020-08-12 13:51 ` Stefan Hajnoczi
2020-08-13 1:51 ` Zhenyu Ye
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=20200918140628.GA2509473@dev \
--to=fam@euphon.net \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=xiexiangyou@huawei.com \
--cc=yezhenyu2@huawei.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).