Messages in this thread |  | | From | Neil Brown <> | Date | Sun, 27 Aug 2000 08:55:17 +1100 (EST) | Subject | Re: ll_rw_blk.c fails to merge requests. Help! |
| |
On Saturday August 26, pochini@denise.shiny.it 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 much.
> > > 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.
NeilBrown - 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/
|  |