Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

quoted

quoted

quoted

quoted

"Tom" == Tom Yan [off-list ref] writes:

Tom,

Tom> Now let's just come back to libata. I've thought of reporting dev->
Tom> max_sectors as Optimal Transfer Length in the SATL. However, I am
Tom> not sure if it is a safe thing to do, because we set it as high as
Tom> 65535 for devices with LBA48 devices. Does such a high max_sectors
Tom> ever make sense in libata's case?

I don't agree with conflating the optimal transfer size and the maximum
supported ditto. Submitting the largest possible I/O to a device does
not guarantee that you get the best overall performance.

 - max_hw_sectors is gated by controller DMA constraints.

 - max_dev_sectors is set for devices that explicitly report a transfer
   length limit.

 - max_sectors, the soft limit for filesystem read/write requests,
   should be left at BLK_DEF_MAX_SECTORS unless the device explicitly
   requests transfers to be aligned multiples of a different value
   (typically the internal stripe size in large arrays).

The point of BLK_DEF_MAX_SECTORS is to offer a reasonable default for
common workloads unless otherwise instructed by the storage device.

We can have a discussion about what the right value for
BLK_DEF_MAX_SECTORS should be. It has gone up over time but it used to
be the case that permitting large transfers significantly impacted
interactive I/O performance. And finding a sweet spot that works for a
wide variety of hardware, interconnects and workloads is obviously
non-trivial.

-- 
Martin K. Petersen	Oracle Linux Engineering