From: Fam Zheng <fam@euphon.net>
To: Zhenyu Ye <yezhenyu2@huawei.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org,
xiexiangyou@huawei.com, armbru@redhat.com,
Stefan Hajnoczi <stefanha@redhat.com>,
pbonzini@redhat.com, mreitz@redhat.com
Subject: Re: [PATCH v1 0/2] Add timeout mechanism to qmp actions
Date: Mon, 21 Sep 2020 11:14:35 +0000 [thread overview]
Message-ID: <20200921111435.GA2524022@dev> (raw)
In-Reply-To: <1ba06b0d-3fcf-3676-f9e0-52875851ff19@huawei.com>
On 2020-09-19 10:22, Zhenyu Ye wrote:
> On 2020/9/18 22:06, Fam Zheng wrote:
> >
> > 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 if any other operation will block the main thread, other
> than io_submit().
Then that's a problem with io_submit which should be fixed. Or more
precisely, that is a long held lock that we should avoid in QEMU's event
loops.
>
> > 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.
>
> Anyway, the qmp timeout may be the last measure to prevent the VM
> soft lockup.
Maybe, but I don't think baking such a workaround into the QMP API is a
good idea. No QMP command should be synchronously long running, so
having a timeout parameter is just a wrong design.
Thanks,
Fam
next prev parent reply other threads:[~2020-09-21 11:17 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
2020-09-19 2:22 ` Zhenyu Ye
2020-09-21 11:14 ` Fam Zheng [this message]
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=20200921111435.GA2524022@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).