Re: [RFC PATCH] mmc: meson-mx-sdhc: add DMA bounce buffer support

[HELPMEEADICE]

Hi Martin,

Thank you again for your feedback!

I've completed the comparison between the original driver,
MMC_CAP2_MERGE_CAPABLE, and the 128 KiB bounce buffer implementation
on my Xunlei OneCloud (Amlogic S805).

The results show that MMC_CAP2_MERGE_CAPABLE alone does not improve
performance on this platform.

Runtime instrumentation confirmed that:

- dma_get_merge_boundary() returns 0.
- host->can_dma_map_merge remains 0.
- The block queue's max_segments remains 1.
- The merge-only variant behaves essentially the same as the original driver.

Here are the sequential read results (MiB/s, mean of 5 runs):

                 Baseline   Merge-only   Bounce
    4 KiB          11.81       12.20      13.01
   64 KiB          12.88       12.80      57.52
  128 KiB          12.97       12.80      67.68
    1 MiB          13.11       13.05      69.43

The bounce buffer improves sequential read throughput by up to 5.3x
and sequential write throughput by up to 2.1x.

For the 128 KiB sequential read test, instrumentation showed that the
number of MMC data requests decreased from 70,599 to 2,465, with the
average request size increasing from approximately 4 KiB to 118 KiB.

I also tested DMA mapping with 33 physically non-contiguous pages.
dma_map_sg() returned 33 DMA segments, confirming that these pages
cannot be merged into a single DMA segment on this platform.

For safety, the tested merge-only variant included a check to reject
DMA mappings with more than one segment. The pure one-line variant was
not executed.

Additionally, I addressed the issue identified by Sashiko by checking
cmd->error before copying bounced read data back and reporting
bytes_xfered.

All 135 fio jobs completed successfully. SHA256 and CRC32C integrity
checks passed, with no MMC errors observed. Fault injection testing
has not yet been performed.

Based on these results, the bounce buffer appears necessary to support
larger MMC requests on this hardware.

I plan to incorporate the error handling fix into the next revision of
the patch.

Please let me know if you have any further suggestions.

Best regards,
Zhenpeng


HELPMEEADICE <yuanzhenpeng210@xxxxxxxxx> 于2026年11月1日周日 16:46写道：
>
> Hi Martin,
>
> Thank you again for your feedback!
>
> I've completed the comparison between the original driver, MMC_CAP2_MERGE_CAPABLE, and the 128 KiB bounce buffer implementation on my Xunlei OneCloud (Amlogic S805).
>
> The results show that MMC_CAP2_MERGE_CAPABLE alone does not improve performance on this platform.
>
> Runtime instrumentation confirmed that:
>
> dma_get_merge_boundary() returns 0.
>
> host->can_dma_map_merge remains 0.
>
> The block queue's max_segments remains 1.
>
> The merge-only variant behaves essentially the same as the original driver.
>
> Here are the sequential read results (MiB/s, mean of 5 runs):
>
>              Baseline   Merge-only   Bounce
> 4 KiB          11.81       12.20      13.01
>
> 64 KiB 12.88 12.80 57.52
> 128 KiB 12.97 12.80 67.68
> 1 MiB 13.11 13.05 69.43
>
> The bounce buffer improves sequential read throughput by up to 5.3x and sequential write throughput by up to 2.1x.
>
> For the 128 KiB sequential read test, instrumentation showed that the number of MMC data requests decreased from 70,599 to 2,465, with the average request size increasing from approximately 4 KiB to 118 KiB.
>
> I also tested DMA mapping with 33 physically non-contiguous pages. dma_map_sg() returned 33 DMA segments, confirming that these pages cannot be merged into a single DMA segment on this platform.
>
> For safety, the tested merge-only variant included a check to reject DMA mappings with more than one segment. The pure one-line variant was not executed.
>
> Additionally, I addressed the issue identified by Sashiko by checking cmd->error before copying bounced read data back and reporting bytes_xfered.
>
> All 135 fio jobs completed successfully. SHA256 and CRC32C integrity checks passed, with no MMC errors observed. Fault injection testing has not yet been performed.
>
> Based on these results, the bounce buffer appears necessary to support larger MMC requests on this hardware.
>
> I plan to incorporate the error handling fix into the next revision of the patch.
>
> Please let me know if you have any further suggestions.
>
> Best regards,
> Zhenpeng
>
>
> Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> 于2026年11月1日周日 05:17写道：
>>
>> Hi,
>>
>> Thank you for this patch!
>>
>> On Sat, Oct 31, 2026 at 9:09 PM ZHENPENG YUAN <yuanzhenpeng210@xxxxxxxxx> wrote:
>> >
>> > The Meson MX SDHC controller uses a single DMA address for each
>> > transfer. Since the driver leaves max_segs at the MMC core default
>> > of 1, large I/O requests are split into single-segment requests,
>> > typically 4 KiB each.
>> >
>> > On an Amlogic S805, this limits eMMC sequential read throughput
>> > to approximately 15 MiB/s despite using HS200 timing.
>> >
>> > Add a 128 KiB DMA bounce buffer for multi-segment requests and
>> FWIW, while reviewing your patch I found that Amlogic actually uses a
>> 512KiB bounce buffer in their downstream driver: [0]
>>
>> > advertise up to 64 scatterlist segments. Single-segment requests
>> > continue to use direct DMA. If buffer allocation fails, fall back
>> > to the original single-segment limit.
>> >
>> > Testing on a Xunlei OneCloud (Meson8b, Samsung 8GME4R eMMC)
>> > running Linux 7.3.1:
>> >
>> >   Block size       Before       After
>> >   4 KiB            14.47        14.69 MiB/s
>> >   64 KiB           15.06        63.21 MiB/s
>> >   128 KiB          15.08        75.13 MiB/s
>> >   1 MiB            15.07        75.93 MiB/s
>> >
>> > For a 128 MiB sequential read, block requests decreased from
>> > 32768 to 1024.
>> That's a nice performance improvement!
>>
>> > Direct I/O SHA256 readback verification and fio CRC32C write
>> > verification passed. No MMC errors were observed.
>> >
>> > Assisted-by: LLM
>> > Signed-off-by: ZHENPENG YUAN <yuanzhenpeng210@xxxxxxxxx>
>> Could you please compare your patch to simply setting mmc->caps2 |=
>> MMC_CAP2_MERGE_CAPABLE; ?
>> From what I understand this will allow physically contiguous SG
>> entries to be merged by mmc core.
>>
>> Ulf: the code here looks similar to the sdhci.c implementation. I'm
>> wondering if there were any plans to somehow move this to MMC core.
>>
>>
>> Best regards,
>> Martin
>>
>>
>> [0] https://github.com/endlessm/linux-meson/blob/d6e13c220931110fe676ede6da69fc61a7cb04b6/arch/arm/mach-meson8/include/mach/sd.h#L627