qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH v2 02/13] block: Introduce bdrv_loc


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 02/13] block: Introduce bdrv_lock and bdrv_unlock API
Date: Wed, 24 Jun 2015 10:35:30 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Jun 24, 2015 at 10:47:47AM +0800, Fam Zheng wrote:
> On Tue, 06/16 17:07, Stefan Hajnoczi wrote:
> > On Tue, Jun 02, 2015 at 11:21:51AM +0800, Fam Zheng wrote:
> > 2. Is this about thread safety?  (No, it's about exclusive access to a
> >    BDS *within* the AioContext.)
> 
> As it has to quiesce iothreads as well (for now it's even more urgent than
> exclusive access within the same AioContext), I'd rather take it as yes.

This mechanism is not about threads and it is also not thread-safe (the
caller must acquire AioContext themselves).

The mechanism is about notifying the users of a drive that no requests
should be submitted.

> BTW, is there any semantics in here that we can use for multiqueue block 
> layer?

The callback to remove/add ioeventfd is needed by multiqueue in the same
way as dataplane.

I think the actual multiqueue I/O will need to be more fine-grained
because the goal is to process I/O requests in parallel and
independently.  Multiqueue should not require exclusive access (which
this mechanism provides) - that would defeat the point of multiqueue.

Stefan

Attachment: pgp53jURZ5L0Z.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]