This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] xen/blkback: Don't let in-flight requests de

To: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] xen/blkback: Don't let in-flight requests defer pending ones.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Tue, 28 Jun 2011 09:19:18 -0400
Cc: "Vincent, Pradeep" <pradeepv@xxxxxxxxxx>, Xen <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 28 Jun 2011 06:20:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1309221107.24771.524.camel@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CA0B31CB.18CDA%pradeepv@xxxxxxxxxx> <1306950593.32587.26.camel@ramone> <20110627140339.GE6978@xxxxxxxxxxxx> <1309200148.24771.13.camel@xxxxxxxxxxxxxxxxxxxxxxx> <20110627191332.GE15703@xxxxxxxxxxxx> <1309221107.24771.524.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Jun 27, 2011 at 05:31:47PM -0700, Daniel Stodden wrote:
> On Mon, 2011-06-27 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jun 27, 2011 at 11:42:28AM -0700, Daniel Stodden wrote:
> > > On Mon, 2011-06-27 at 10:03 -0400, Konrad Rzeszutek Wilk wrote:
> > > > > In the case at hand, increasing the ring size was way more productive.
> > > > > At which point the queue depth multiplies as well. And I currently
> > > > > expect that the longer it gets the more urgent the issue you describe
> > > > > will be.
> > > > 
> > > > You wouldn't have patches for that somewhere tucked away? I am going 
> > > > over
> > > > the patches for 3.1 xen-blkback and was thinking to have them all 
> > > > queued up and
> > > > test them all at once..
> > > 
> > > I was going to send the kernel patch right after, just to discover that
> > > xen-blkback lacks some of the synchronization items the original one was
> > > based on. It's coming, but it's rather going to be a series.
> > 
> > That is fine. Please also CC lkml when posting the series. Thanks!
> That's a more interesting thing, actually: Do you plan to maintain this

That is my plan.
> stuff? Because xen-blkback presently has no dedicated MAINTAINERS entry,

You are right. I should send a patch to explicitly state it, even thought this:

$scripts/get_maintainer.pl -f drivers/block/xen-blkback/
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> (commit_signer:31/32=97%)
Laszlo Ersek <lersek@xxxxxxxxxx> (commit_signer:2/32=6%)
Jan Beulich <jbeulich@xxxxxxxxxx> (commit_signer:2/32=6%)
linux-kernel@xxxxxxxxxxxxxxx (open list)

Kind of makes me the top choice.
> iirc, so I guess it defaults to Jens.

Well, everything under drivers/block _has_ to eventually go through Jens.
It can go first through xen-devel to make sure there is nothing bogus, and
be reviewed here. And I can collect the patches, stick them in a branch,
run through the Xen gauntlet tests and then ask Jens to GIT PULL them.

It does not hurt to additionaly go through LKML - more eyes the better.
> It might indeed make more sense to collect tested batches, and submit
> them as such.

<nods> So far I've:

    xen/blkback: Don't let in-flight requests defer pending ones.


And I wouldn't mind putting some more there before I start cranking some

Xen-devel mailing list