linux-kernel - RE: async I/O seems to be blocking on 2.6.15

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:	Mon, 6 Nov 2006 16:24:18 -0800
From:	"Chen, Kenneth W" <kenneth.w.chen@...el.com>
To:	"'Brent Baccala'" <cosine@...esoft.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: async I/O seems to be blocking on 2.6.15

Brent Baccala wrote on Monday, November 06, 2006 4:04 PM
> On Mon, 6 Nov 2006, Chen, Kenneth W wrote:
> > I've tried that myself too and see similar result.  One thing to note is
> > that I/O being submitted are pretty big at 1MB, so the vector list inside
> > bio is going to be pretty long and it will take a while to construct that.
> > Drop the size for each I/O to something like 4KB will significantly reduce
> > the time.  I haven't done the measurement whether the time to submit I/O
> > grows linearly with respect to I/O size.  Most likely it will.  If it is
> > not, then we might have a scaling problem (though I don't believe we have
> > this problem).
> 
> I'm basically an end user here (as far as the kernel is concerned), so
> let me ask the basic "dumb user" question here:
> 
> How should I do my async I/O if I just want to read or write
> sequentially through a file, using O_DIRECT, and letting the CPU get
> some work done in the meantime?  What about more random access?
> 
> I've already concluded that I should try to keep my read and write
> files on seperate disks and hopefully on seperate controllers, but I
> still seem to be fighting this thing to keep it from blocking.


You bark rightfully at the fact that kernel blocks in the async path when
block queue is full. It would be nice that -EAGAIN is returned so app can
do other stuff.

My earlier post was commenting on the measurement of I/O submit when
nothing blocks (which happens to be extremely important to me).  Your
measurement of 7ms seems excessive. While mine and Jens came at around
90 micro-second which isn't all that unreasonable given the size of the
I/O request.

- Ken

-
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/