From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Re: [PATCH] xen/blkback: Don't let in-flight requests defer pending ones. Date: Tue, 28 Jun 2011 09:19:18 -0400 Message-ID: <20110628131917.GB7777@dumpdata.com> References: <1306950593.32587.26.camel@ramone> <20110627140339.GE6978@dumpdata.com> <1309200148.24771.13.camel@agari.van.xensource.com> <20110627191332.GE15703@dumpdata.com> <1309221107.24771.524.camel@agari.van.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1309221107.24771.524.camel@agari.van.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Stodden Cc: "Vincent, Pradeep" , Xen , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 (commit_signer:31/32=97%) Laszlo Ersek (commit_signer:2/32=6%) Jan Beulich (commit_signer:2/32=6%) linux-kernel@vger.kernel.org (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. So far I've: xen/blkback: Don't let in-flight requests defer pending ones. (#stable/for-jens) And I wouldn't mind putting some more there before I start cranking some tests.