Messages in this thread | | | From | Al Boldi <> | Subject | Re: What's in linux-2.6-block.git | Date | Wed, 13 Sep 2006 20:52:48 +0300 |
| |
Jens Axboe wrote: > 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.
Not really, as this drive is the only one supporting max_sectors_kb>128.
Thanks!
-- Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |