On Fri, Oct 28 2005, Mike Christie wrote: > 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. Certainly! > 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? On the SCSI side, I would suggest just making shost->max_sectors set q->max_hw_sectors and leave q->max_sectors to some generic kernel-wide block layer define (of course making sure that ->max_sectors <= ->max_hw_sectors). That's the easy part. The bio_add_page() stuff is a little trickier, since it wants to know if this is fs or 'generic' io. For fs io, we would like to cap the building of the bio to ->max_sectors, but for eg SG_IO issued io it should go as high as ->max_hw_sectors. Perhaps the easiest is just to have bio_fs_add_page() and bio_pc_add_page(), each just passing in the max value as an integer to bio_add_page(). But it's not exactly pretty. The ll_rw_blk.c merging is easy, since you don't need to do anything there. It should test against ->max_sectors as it already does, since this (sadly) is still the primary way we build large ios. Make sense? -- Jens Axboe - : 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
