Re: [PATCH] mmc:mmc-hsq:use fifo to dispatch mmc_request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/18/2022 7:43 PM, Wenchao Chen wrote:
On Fri, Nov 18, 2022 at 1:52 PM Michael Wu <michael@xxxxxxxxxxxxxxxxx> wrote:

Current next_tag selection will cause a large delay in some requests and
destroy the scheduling results of the block scheduling layer. Because the
issued mrq tags cannot ensure that each time is sequential, especially when
the IO load is heavy. In the fio performance test, we found that 4k random
read data was sent to mmc_hsq to start calling request_atomic It takes
nearly 200ms to process the request, while mmc_hsq has processed thousands
of other requests. So we use fifo here to ensure the first in, first out
feature of the request and avoid adding additional delay to the request.


Hi Michael
Is the test device an eMMC?
Could you share the fio test command if you want?
Can you provide more logs?

Hi Wenchao,
Yes, the tested device is emmc.
The test command we used is `./fio -name=Rand_Read_IOPS_Test -group_reporting -rw=random -bs=4K -numjobs=8 -directory=/data/data -size=1G -io_size=64M -nrfiles=1 -direct=1 -thread && rm /data/Rand_Read_IOPS_Test *`, which replaces the io performance random read performance test of androidbench, and the file size is set to 1G, 8 thread test configuration. Where /data uses f2fs and /data/data is a file encrypted path.

After enabling the hsq configuration, we can clearly see from below fio test log that the minimum value of random reading is 3175 iops and the maximum value is 8554iops, and the maximum delay of io completion is about 200ms.
```
    clat percentiles (usec):
| 1.00th=[ 498], 5.00th=[ 865], 10.00th=[ 963], 20.00th=[ 1045], | 30.00th=[ 1090], 40.00th=[ 1139], 50.00th=[ 1172], 60.00th=[ 1221], | 70.00th=[ 1254], 80.00th=[ 1319], 90.00th=[ 1401], 95.00th=[ 1614], | 99.00th=[ 2769], 99.50th=[ 3589], 99.90th=[ 31589], 99.95th=[ 66323],
     | 99.99th=[200279]
bw ( KiB/s): min=12705, max=34225, per=100.00%, avg=23931.79, stdev=497.40, samples=345 iops : min= 3175, max= 8554, avg=5981.67, stdev=124.38, samples=345
```


```
    clat percentiles (usec):
     |  1.00th=[  799],  5.00th=[  938], 10.00th=[  963], 20.00th=[  979],
     | 30.00th=[  996], 40.00th=[ 1004], 50.00th=[ 1020], 60.00th=[ 1045],
     | 70.00th=[ 1074], 80.00th=[ 1106], 90.00th=[ 1172], 95.00th=[ 1237],
     | 99.00th=[ 1450], 99.50th=[ 1516], 99.90th=[ 1762], 99.95th=[ 2180],
     | 99.99th=[ 9503]
bw ( KiB/s): min=29200, max=30944, per=100.00%, avg=30178.91, stdev=53.45, samples=272 iops : min= 7300, max= 7736, avg=7544.62, stdev=13.38, samples=272
```
When NOT enabling hsq, the minimum value of random reading is 7300 iops and the maximum value is 7736 iops, and the maximum delay of io is only 9 ms. Finally, we added debug to the mmc driver. The reason for locating the 200ms delay of hsq is due to the next tag selection of hsq.

---
Michael Wu



[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux