Jens Axboe wrote:
On Sun, Oct 23 2005, Jeff Garzik wrote:
Douglas Gilbert wrote:
Which in turn makes me think of applying the same idea
to max_sectors
shost->max_sectors = MAX_512B_SECTORS_UNLIMITED;
Won't work. max_sectors is communicated to the block layer, where we
limit the overall size of the request for practical reasons.
Read the comment in libata-scsi's slave_configure:
/* TODO: 1024 is an arbitrary number, not the
* hardware maximum. This should be increased to
* 65534 when Jens Axboe's patch for dynamically
* determining max_sectors is merged.
*/
Right now, setting the true hardware / command set maximum would use way
too much memory, with no way to get feedback from the VM.
This is why SCSI_DEFAULT_MAX_SECTORS is defined to 1024.
The block layer has had split values for quite some time, ->max_sectors
and max_hw_sectors. scsi_ioctl.c needs a patch to look at max_hw_sectors
instead and SCSI drivers could then easily be updated to advertise a
real hardware value as well. That is what shost->max_sectors should be,
SCSI mid layer would then set q->max_sectors to SCSI_DEFAULT_MAX_SECTORS
and q->max_hw_sectors to shost->max_sectors.
Then the limiting factor becomes BIO_MAX_PAGES for mapping in the user
data, which caps us at 1MiB currently.
I was just wondering if you give a little more detail in case someone
wanted to implement this for you.
Would the bio functions like __bio_add_page() and bio_get_nr_vecs()
continue to test against q->max_sectors. And then have the request
merging code test against q->max_hw_sectors. scsi or blk would need some
check that max_sectors was not larger than max_sectors, and for scsi we
would have to increase SCSI_DEFAULT_MAX_SECTORS to 2048 to match the
1MiB limit and not make q->max_sectors the limit factor. Or how would
this work?
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
