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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Sep 2006 12:59:32 +0200
From:	Jens Axboe <axboe@...nel.dk>
To:	Al Boldi <a1426z@...ab.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: What's in linux-2.6-block.git

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?

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/