On Tue, Jan 25 2000, Eric Youngdale wrote:
[broken request merging]
> If I had to take a guess, I would venture that the problem has to do
> with the way that plugging was implemented. I believe that what is going on
> is that read ahead isn't kicking in until after the first read request.
> Thus you get a really small request for the first one, and once the block
> driver notices that you are requesting consecutive blocks, read-ahead starts
> to kick in and the request size starts to increase.
But this if for writes, not reads. I haven't investigated the read aheads
yet, but the device plugging may be guilty for the writing as well.
> The other thing that I have been noticing - some people have complained
> that the request size never exceeds 64K. My *guess* here is that what we
> are doing is inserting the plug, requesting the sectors for an entire page
> of memory, and then unplugging. This cannot be the entire explaination, as
> once the device is busy and no longer accepting requests, plugging becomes
> irrelevant.
The ll_rw_block layer will not merge requests beyond max_sectors /
max_segments which, again, is a per-major kind of thing. Has anyone
experimented with setting this higher? The DAC960 is currently
the only driver manipulating it. The default value is indeed 128
sectors, or 64KB.
> For SCSI disks, the read ahead is set to 120 sectors - just a tad under
> 64K. For SCSI CDROM, it is set to 32 sectors - the thing I am not sure
> about is whether this always refers to "sectors" of 512 bytes, or it
> reflects the hardware sectorsize. Look for "read_ahead" in both sd.c and
> sr.c to see where this is set.
Even though the readahead should be set as low as 120 sectors (512
byte units here), there would be nothing wrong in allowing a much
large clustered request. But hey, the drivers can pick and choose
it's just that noone is doing it yet.
> If I could get the simulator running again, you could just step through
> the kernel with gdb and see for yourself how all of this stuff interacts.
> Then again, I probably have an older executable based upon a 2.3.8 kernel
> which you could probably run - let me take a look tonight.
I'd like to see it.
--
* Jens Axboe <[EMAIL PROTECTED]>
* Linux CD-ROM Maintainer
* http://www.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
