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.
Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz
Managing Director: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782
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/[email protected]/).
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/[email protected]/).
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/[email protected]/).
>
> 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/[email protected]/).
>>
>> 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.