[lkml]   [2000]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ll_rw_blk.c fails to merge requests. Help!
On Saturday August 26, wrote:
> > Please try the following (totally untested I'm afraid) patch and see
> > if it makes a difference.
> > It basically retries the merge after waiting for a request, and then
> > either releases the request if the merge was successful, or uses that
> > request to add the bh to the queue.
> It works much better, but it still fails to merge blocks. The following
> is a report of write requests directly from the scsi driver:
> (I'm now using -test7)
> 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.

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.
To test that this is the issue, you could change NBUF in block_dev.c
to 63.

Alternatively, you could create a filesystem on the device and write
to that. You don't get synchronous writes then so you shouldn't get
the small requests nearly as

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.092 / U:2.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site