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