> > Aug 26 18:09:19 Jay kernel: W 914680 252
> > Aug 26 18:09:19 Jay kernel: W 914932 8
> > Aug 26 18:09:19 Jay kernel: W 851976 4
> > Aug 26 18:09:19 Jay kernel: W 914940 252
> > Aug 26 18:09:19 Jay kernel: W 915192 4
> > Aug 26 18:09:19 Jay kernel: W 915196 252
> > Aug 26 18:09:19 Jay kernel: W 915448 12
> > Aug 26 18:09:19 Jay kernel: W 915460 252
> > Aug 26 18:09:19 Jay kernel: W 915712 4
> > Aug 26 18:09:19 Jay kernel: W 915716 252
>
> As you have 2K blocks, 252 is the largest number of sectors that can
> fit into a request (MAX_SECTORS == 254).
> So it looks like you are getting 128k synchronous IO requests, which
> are being broken into one 126K request and one 2K request.
>
> If these were READ requests, I would blame the read-ahead code. It
> currently always does synchronous read-ahead (I sent a patch to
> linux-kernel a while back but it hasn't made it into test7. I'll
> resubmit to Linus. But I assume that the 'W' means that these are
> write requests.
Yes.
> If you are writing out to the block device (cat > /dev/sdxx) then
> you would get 128k synchronous requests: block_dev.c(block_write)
> collects 64 buffers together and writes them out syncronously.
> With a 2k block size, that is 128k.
No, I'm doing "cat /dev/zero >file" as usual and it writes a block a
time.
> > > It also contains some (fairly ugly) code inside #ifdef
> > > STRICT_REQUEST_ORDERING which should encourage a strict ordering for
> > > threads to get the request structures they are waiting for.
> >
> > It makes no difference.
>
> I didn't expect it to, but thanks for checking.
I too, but why not to try ?
Bye.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:24 EST