From: Kevin Wolf <kwolf@redhat.com>
To: Zhenyu Ye <yezhenyu2@huawei.com>
Cc: qemu-devel@nongnu.org, armbru@redhat.com, mreitz@redhat.com,
qemu-block@nongnu.org, qemu-trivial@nongnu.org,
xiexiangyou@huawei.com
Subject: Re: [PATCH v1] qmp: don't hold ctx lock while querying blockstats
Date: Fri, 10 Jul 2020 11:40:26 +0200 [thread overview]
Message-ID: <20200710094026.GC6641@linux.fritz.box> (raw)
In-Reply-To: <20200710085400.343-1-yezhenyu2@huawei.com>
Am 10.07.2020 um 10:54 hat Zhenyu Ye geschrieben:
> Because the QMP command runs in the main thread, and changes
> to the aio context of iothread will only be executed in the
> main thread (they will not be in parallel), so there is no
> need a lock protection while querying blockstats.
>
> If we hold the lock here, while the I/O pressure is high in
> vm and the I/O returns slowly, the main thread will be stuck
> until the lock is released, which will affect the vcpu operation
> and finall cause the vm to be stuck.
>
> Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com>
Are you saying that you think qmp_query_blockstats() runs in the
iothread? This is not true, it runs in the main thread.
This makes dropping the lock wrong, and even dropping it shouldn't make
a difference for other things that should run in the main thread because
the main thread is still busy executing the QMP command.
Am I missing something?
(Also, a change like this is most definitely *not* trivial.)
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Wolf <kwolf@redhat.com>
To: Zhenyu Ye <yezhenyu2@huawei.com>
Cc: qemu-block@nongnu.org, qemu-trivial@nongnu.org,
armbru@redhat.com, qemu-devel@nongnu.org, xiexiangyou@huawei.com,
mreitz@redhat.com
Subject: Re: [PATCH v1] qmp: don't hold ctx lock while querying blockstats
Date: Fri, 10 Jul 2020 11:40:26 +0200 [thread overview]
Message-ID: <20200710094026.GC6641@linux.fritz.box> (raw)
In-Reply-To: <20200710085400.343-1-yezhenyu2@huawei.com>
Am 10.07.2020 um 10:54 hat Zhenyu Ye geschrieben:
> Because the QMP command runs in the main thread, and changes
> to the aio context of iothread will only be executed in the
> main thread (they will not be in parallel), so there is no
> need a lock protection while querying blockstats.
>
> If we hold the lock here, while the I/O pressure is high in
> vm and the I/O returns slowly, the main thread will be stuck
> until the lock is released, which will affect the vcpu operation
> and finall cause the vm to be stuck.
>
> Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com>
Are you saying that you think qmp_query_blockstats() runs in the
iothread? This is not true, it runs in the main thread.
This makes dropping the lock wrong, and even dropping it shouldn't make
a difference for other things that should run in the main thread because
the main thread is still busy executing the QMP command.
Am I missing something?
(Also, a change like this is most definitely *not* trivial.)
Kevin
next prev parent reply other threads:[~2020-07-10 9:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 8:54 [PATCH v1] qmp: don't hold ctx lock while querying blockstats Zhenyu Ye
2020-07-10 8:54 ` Zhenyu Ye
2020-07-10 9:27 ` no-reply
2020-07-10 9:27 ` no-reply
2020-07-10 9:40 ` Kevin Wolf [this message]
2020-07-10 9:40 ` Kevin Wolf
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=20200710094026.GC6641@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.