qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH 00/16] AioContext fine-grained locking, part 1 o


From: Stefan Hajnoczi
Subject: Re: [Qemu-block] [PATCH 00/16] AioContext fine-grained locking, part 1 of 3, including bdrv_drain rewrite
Date: Fri, 18 Mar 2016 15:49:47 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Thu, Mar 17, 2016 at 02:48:00PM +0100, Paolo Bonzini wrote:
> 
> 
> On 17/03/2016 14:44, Stefan Hajnoczi wrote:
> > > For example, each part will probably have an uncontroversial and
> > > generally useful prefix---for example patches 1-4 in this case, or the
> > > change to a single linux-aio context per iothread.  You could merge
> > > those only, and for the rest, I will maintain myself a branch with R-b
> > > from maintainers.  Master will be periodically merged into it, but not
> > > too frequently---it could be only after each part is accepted, or when
> > > there is some important bugfix to catch.  Once the whole multiqueue
> > > thing gets somewhere I would send you a pull request with the entire
> > > feature, which would consist of say 200 patches all with a Reviewed-by
> > > already.
> > > 
> > > This is just a possibility; if you have any other idea, I'd be happy to
> > > follow it.
> >
> > That sounds reasonable.  I guess you are sending a) infrastructure and safe
> > changes alongside b) longer-term work.  If you indicate which patches
> > are a) then that makes it easier to merge parts into qemu.git before all
> > the long-term work is complete.
> 
> Great, let's try it then.  For this series (well, for v2 of this series)
> only patches 1-4 would be considered infrastructure.  They were sent
> before soft freeze, would they be acceptable for 2.6?
> 
> In general I would send "safe" patches as [PATCH mm/nn] and everything
> else as [PATCH multiqueue mm/nn] or similar, but in either case I'd be
> seeking formal maintainer review as soon as I send them.

Okay.  I'll hope over to the v2 series to take a look.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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