Re: What's in linux-2.6-block.git

[Jens Axboe <axboe@kernel.dk>]

On Wed, Sep 13 2006, Al Boldi wrote:
> Jens Axboe wrote:
> > On Wed, Sep 13 2006, Al Boldi wrote:
> > > Jens Axboe  wrote:
> > > > This lists the main features of the 'block' branch, which is bound for
> > > > Linus when 2.6.19 opens:
> > > >
> > > > - Splitting of request->flags into two parts:
> > > >         - cmd type
> > > >         - modified flags
> > > >   Right now it's a bit of a mess, splitting this up invites a cleaner
> > > >   usage and also enables us to implement generic "messages" passed on
> > > >   the regular queue for the device.
> > > >
> > > > - Abstract out the request back merging and put it into the core io
> > > >   scheduler layer. Cleans up all the io schedulers, and noop gets
> > > >   merging for "free".
> > > >
> > > > - Abstract out the rbtree sorting. Gets rid of duplicated code in
> > > >   as/cfq/deadline.
> > > >
> > > > - General shrinkage of the request structure.
> > > >
> > > > - Killing dynamic rq private structures in deadline/as/cfq. This
> > > > should speed up the io path somewhat, as we avoid allocating several
> > > > structures (struct request + scheduler private request) for each io
> > > > request.
> > > >
> > > > - meta data io logging for blktrace.
> > > >
> > > > - CFQ improvements.
> > > >
> > > > - Make the block layer configurable through Kconfig (David Howells).
> > > >
> > > > - Lots of cleanups.
> > >
> > > Does it also address the strange "max_sectors_kb<>192 causes a
> > > 50%-slowdown" problem?
> >
> > (remember to cc me/others when replying, I can easily miss lkml
> > messages for several days otherwise).
> >
> > It does not, the investigation of that is still pending I'm afraid. The
> > data is really puzzling, I'm inclined to think it's drive related. Are
> > you reproducing it just one box/drive, or on several?
> 
> Several boxes, same drive.

Have you / can you try and reproduce with another drive as well? It'd be
an interesting data point.

-- 
Jens Axboe