| Message ID | f30ec7fe7d834c1d8e116508500110cf@hyperstone.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mmc: Improve block layer requeueing behavior | expand |
On 26/10/22 10:30, Christian Löhle wrote: > Mmcblk relies on block layer requeueing to fulfill some requests under > certain conditions. Improve the handling to get nicely ordered requests. > > Using the terms a bit loosely to get a point across: > Current behavior for 512 blksz and max_blk_count = 1 the scenario would > be as follows: > > - request for page 0 lba 0 to 7 > - request for page 1 lba 8 to 15 > - request for page 2 lba 16 to 23 > - request for page 3 lba 24 to 31 > > mmcblk modifies data->blocks = 1 for each and requeues, > this leads to: > > Access lba 0 > Access lba 8 > Access lba 16 > Access lba 24 > Access lba 1 (1. Requeue for page 0) > Access lba 9 (1. Requeue for page 1) > Access lba 17 (1. Requeue for page 2) > Access lba 25 (1. Requeue for page 3) > Access lba 2 (2. Requeue for page 0) > ... > > Of course we would rather have lbas consecutive. Does anyone know why the block layer does not support (max_hw_sectors << 9) < PAGE_SIZE ?
On 11/18/22 02:47, Adrian Hunter wrote: > On 26/10/22 10:30, Christian Löhle wrote: >> Mmcblk relies on block layer requeueing to fulfill some requests under >> certain conditions. Improve the handling to get nicely ordered requests. >> >> Using the terms a bit loosely to get a point across: >> Current behavior for 512 blksz and max_blk_count = 1 the scenario would >> be as follows: >> >> - request for page 0 lba 0 to 7 >> - request for page 1 lba 8 to 15 >> - request for page 2 lba 16 to 23 >> - request for page 3 lba 24 to 31 >> >> mmcblk modifies data->blocks = 1 for each and requeues, >> this leads to: >> >> Access lba 0 >> Access lba 8 >> Access lba 16 >> Access lba 24 >> Access lba 1 (1. Requeue for page 0) >> Access lba 9 (1. Requeue for page 1) >> Access lba 17 (1. Requeue for page 2) >> Access lba 25 (1. Requeue for page 3) >> Access lba 2 (2. Requeue for page 0) >> ... >> >> Of course we would rather have lbas consecutive. > > Does anyone know why the block layer does not support > (max_hw_sectors << 9) < PAGE_SIZE ? Hi Adrian, Does this mean that the following patch series would not only be useful for UFS but also for MMC? "[PATCH 00/10] Support DMA segments smaller than the page size" (https://lore.kernel.org/linux-block/20221019222324.362705-1-bvanassche@acm.org/). Thanks, Bart.
On 18/11/22 19:27, Bart Van Assche wrote: > On 11/18/22 02:47, Adrian Hunter wrote: >> On 26/10/22 10:30, Christian Löhle wrote: >>> Mmcblk relies on block layer requeueing to fulfill some requests under >>> certain conditions. Improve the handling to get nicely ordered requests. >>> >>> Using the terms a bit loosely to get a point across: >>> Current behavior for 512 blksz and max_blk_count = 1 the scenario would >>> be as follows: >>> >>> - request for page 0 lba 0 to 7 >>> - request for page 1 lba 8 to 15 >>> - request for page 2 lba 16 to 23 >>> - request for page 3 lba 24 to 31 >>> >>> mmcblk modifies data->blocks = 1 for each and requeues, >>> this leads to: >>> >>> Access lba 0 >>> Access lba 8 >>> Access lba 16 >>> Access lba 24 >>> Access lba 1 (1. Requeue for page 0) >>> Access lba 9 (1. Requeue for page 1) >>> Access lba 17 (1. Requeue for page 2) >>> Access lba 25 (1. Requeue for page 3) >>> Access lba 2 (2. Requeue for page 0) >>> ... >>> >>> Of course we would rather have lbas consecutive. >> >> Does anyone know why the block layer does not support >> (max_hw_sectors << 9) < PAGE_SIZE ? > > Hi Adrian, > > Does this mean that the following patch series would not only be > useful for UFS but also for MMC? "[PATCH 00/10] Support DMA segments > smaller than the page size" > (https://lore.kernel.org/linux-block/20221019222324.362705-1-bvanassche@acm.org/). That patchset still does not allow max_hw_sectors = 1 which is what Christian's case needs.
On 11/21/22 00:25, Adrian Hunter wrote: > On 18/11/22 19:27, Bart Van Assche wrote: >> On 11/18/22 02:47, Adrian Hunter wrote: >>> Does anyone know why the block layer does not support >>> (max_hw_sectors << 9) < PAGE_SIZE ? >> >> Does this mean that the following patch series would not only be >> useful for UFS but also for MMC? "[PATCH 00/10] Support DMA segments >> smaller than the page size" >> (https://lore.kernel.org/linux-block/20221019222324.362705-1-bvanassche@acm.org/). > > That patchset still does not allow max_hw_sectors = 1 which is > what Christian's case needs. Hi Adrian, Why would that patch series not support max_hw_sectors = 1? What am I overlooking? Thanks, Bart.
On 21/11/22 21:14, Bart Van Assche wrote: > On 11/21/22 00:25, Adrian Hunter wrote: >> On 18/11/22 19:27, Bart Van Assche wrote: >>> On 11/18/22 02:47, Adrian Hunter wrote: >>>> Does anyone know why the block layer does not support >>>> (max_hw_sectors << 9) < PAGE_SIZE ? >>> >>> Does this mean that the following patch series would not only be >>> useful for UFS but also for MMC? "[PATCH 00/10] Support DMA segments >>> smaller than the page size" >>> (https://lore.kernel.org/linux-block/20221019222324.362705-1-bvanassche@acm.org/). >> >> That patchset still does not allow max_hw_sectors = 1 which is >> what Christian's case needs. > > Hi Adrian, > > Why would that patch series not support max_hw_sectors = 1? What am I overlooking? blk_queue_max_hw_sectors() does not allow it.
On 11/21/22 11:42, Adrian Hunter wrote:
> blk_queue_max_hw_sectors() does not allow it.
Right, I modified blk_queue_max_segment_size() in my patch series but
not blk_queue_max_hw_sectors(). Adding a change for
blk_queue_max_hw_sectors() to that patch series should be easy since
that patch series already adds support for max_sectors being smaller
than the page size.
Thanks,
Bart.
> > On 11/21/22 11:42, Adrian Hunter wrote: > > blk_queue_max_hw_sectors() does not allow it. > > Right, I modified blk_queue_max_segment_size() in my patch series but not > blk_queue_max_hw_sectors(). Adding a change for > blk_queue_max_hw_sectors() to that patch series should be easy since that > patch series already adds support for max_sectors being smaller than the > page size. Once you do, please publish it to the scsi mailing list as well. Thanks, Avri > > Thanks, > > Bart.
On 11/21/22 23:21, Avri Altman wrote:
> Once you do, please publish it to the scsi mailing list as well.
I will Cc the linux-scsi mailing list.
Thanks,
Bart.