[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread |
Date: |
Tue, 22 Aug 2017 10:56:54 +0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Tue, Aug 22, 2017 at 10:15:56AM +0800, Fam Zheng wrote:
> On Mon, 08/21 18:28, Dr. David Alan Gilbert wrote:
> > > It's not much more than asserting qemu_mutex_iothread_locked(), the
> > > problem is
> > > the new monitor thread breaks certain assumptions that was true.
> > >
> > > What is interesting in this is that block layer's nested aio_poll() now
> > > not only
> > > run in the main thread but also in the monitor thread. Bugs may hide
> > > there. :)
> > >
> > > That's why I suggested a "safe by default" strategy.
> >
> > OK, that's going to need some more flags somewhere; we've now
> > effectively got three types of command:
> > a) Commands that can only run in the main thread
> > b) Commands that can run in other monitor threads, but must have the bql
> > c) Commands that can run in other monitor threads but don't take the
> > bql
> >
> > The class (a) that you point out are a pain; arguably if we have to
> > split them up then perhaps we should initially only allow (c).
Good to know that this series may break something; That's really what
I want to know for this RFC post. :-)
I agree with Dave that if we assume (a) unchangable, then the only way
to go is only allow (c) in threaded monitors.
However before that, I am curious about whether we can replace the
assertion with something else like locks? And how hard would it be?
(Paolo?)
> >
> > > One step back, is it possible to "unblock" main thread even upon network
> > > issue?
> > > What is the scenario that causes main thread hang? Is there a backtrace?
> >
> > There are at least 3 scenarious I know of:
> >
> > a) Postcopy: An IO operation takes the lock and accesses guest memory;
> > the guest memory is missing due to userfault'd memory.
> > Unfortunately the network connection to the source happens to fail;
> > so we never receive that page and the thread stays stuck in the
> > userfault.
> > We can't issue a recovery command to reopen a network connection
> > because the monitor is blocked.
> > b) Postcopy: A monitor command either accesses guest memory or has
> > to wait on another thread that is doing; e.g. info cpu waits
> > for the CPU threads to exit the loop, but they might be blocked
> > waiting on userfault.
> > c) COLO or migration: The network fails during the critical bit
> > at the end of migration when we have the bql held. You can't
> > issue a migration_cancel or a colo-failover via the monitor
> > because it's blocked.
>
> Thanks for explainaing!
>
> What commands are in class (c)? From the cover letter it seems
> migrate-incoming
> is the only one in mind, I'm not sure how it resolves any of the three
> scenarios?
I haven't really encountered (c), but I think it's the migrate_cancel
command that matters, which should not need BQL as well. For (a) and
(b), they should both need the other migrate_incoming command.
Thanks,
>
> >
> > There are other advantages of being able to do bql'less commands;
> > things like an 'info status' or the like should be doable without bql,
> > so just avoding taking the bql when the management layer is doing
> > stuff (or alternatively getting faster replies on management)
> > are both useful.
>
> Agreed. It is very useful not just for migration.
>
> Fam
--
Peter Xu
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, (continued)
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Fam Zheng, 2017/08/21
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Fam Zheng, 2017/08/21
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/08/21
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Fam Zheng, 2017/08/21
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/08/21
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Fam Zheng, 2017/08/21
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread,
Peter Xu <=
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Fam Zheng, 2017/08/22
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Peter Xu, 2017/08/22
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Fam Zheng, 2017/08/22
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Peter Xu, 2017/08/22
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/08/22
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Fam Zheng, 2017/08/22
- Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/08/22
Re: [Qemu-devel] [RFC 0/6] monitor: allow per-monitor thread, no-reply, 2017/08/22