From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoayO-0003Bw-52 for qemu-devel@nongnu.org; Mon, 17 Jun 2013 11:04:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UoayM-0006Gc-Qg for qemu-devel@nongnu.org; Mon, 17 Jun 2013 11:04:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoayM-0006GV-I3 for qemu-devel@nongnu.org; Mon, 17 Jun 2013 11:03:58 -0400 Message-ID: <51BF2530.2010101@redhat.com> Date: Mon, 17 Jun 2013 17:03:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1371203313-26490-1-git-send-email-stefanha@redhat.com> <1371203313-26490-9-git-send-email-stefanha@redhat.com> <51BB24B0.9070503@redhat.com> <20130617145757.GA31444@stefanha-thinkpad.redhat.com> In-Reply-To: <20130617145757.GA31444@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 08/13] block: drop bdrv_get_aio_context() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , Ping Fan Liu , qemu-devel@nongnu.org, Stefan Hajnoczi Il 17/06/2013 16:57, Stefan Hajnoczi ha scritto: > On Fri, Jun 14, 2013 at 10:12:00AM -0400, Paolo Bonzini wrote: >> Il 14/06/2013 05:48, Stefan Hajnoczi ha scritto: >>> Associating a BlockDriverState with a single AioContext is not flexible >>> enough. Once we make BlockDriverState thread-safe, it will be possible >>> to call bdrv_*() functions from multiple event loops. >> >> I'm afraid that this is trading some pain now (converting >> qemu_bh_new/qemu_set_fd_handler to aio_bh_new/aio_set_fd_handler) for >> more pain later (having to make BDS thread-safe). There aren't that >> many (~40) in block layer code. >> >> Making BlockDriverState thread-safe is hard, it is much simpler to run >> all the BlockDriverState code in the AioContext thread itself. >> >> There are some things that cannot (basically monitor commands and other >> places that are currently using bdrv_drain_all) but they can simply take >> a "big AioContext lock". > > I don't like a big AioContext lock that stops the event loop because we > need to support a M:N device:iothread model where stopping an event loop > means artificially stopping other devices too. The event loop would still run via aio_wait(), just in the monitor thread. However it would stop the ioeventfd, through a mechanism such as the one you added in this thread or something like that. > Maybe it's workable though since the only commands that would take an > AioContext lock are rare and shouldn't impact performance. Yes. > I guess then > it comes down to robustness if a hung NFS mount can affect the entire VM > instead of just hanging an emulated disk device. That would only be a hung NFS mount while running something that drains a BDS, no? It would hang the monitor, but it wouldn't be a regression compared to what we have now obviously. Paolo