mmc:mmc-hsq:use fifo to dispatch mmc_request

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.

Signed-off-by Michael Wu <[email protected]>

---
 drivers/mmc/host/mmc_hsq.c | 40 ++++++++++++++------------------------
 drivers/mmc/host/mmc_hsq.h |  5 +++++
 2 files changed, 20 insertions(+), 25 deletions(-)

drivers/mmc/host/mmc_hsq.c +15 -25

index 9d35453e7371..d2a1a96ed5bd 100644
@@ -13,9 +13,6 @@
 
 #include "mmc_hsq.h"
 
-#define HSQ_NUM_SLOTS  64
-#define HSQ_INVALID_TAG        HSQ_NUM_SLOTS
-
 static void mmc_hsq_retry_handler(struct work_struct *work)
 {
        struct mmc_hsq *hsq = container_of(work, struct mmc_hsq, retry_work);

@@ -73,7 +70,6 @@ static void mmc_hsq_pump_requests(struct mmc_hsq *hsq)
 
 static void mmc_hsq_update_next_tag(struct mmc_hsq *hsq, int remains)
 {
-       struct hsq_slot *slot;
        int tag;
 
        /*

@@ -82,29 +78,12 @@ static void mmc_hsq_update_next_tag(struct mmc_hsq *hsq, int remains)
         */
        if (!remains) {
                hsq->next_tag = HSQ_INVALID_TAG;
+               hsq->tag_tail = HSQ_INVALID_TAG;
                return;
        }
 
-       /*
-        * Increasing the next tag and check if the corresponding request is
-        * available, if yes, then we found a candidate request.
-        */
-       if (++hsq->next_tag != HSQ_INVALID_TAG) {
-               slot = &hsq->slot[hsq->next_tag];
-               if (slot->mrq)
-                       return;
-       }
-
-       /* Othersie we should iterate all slots to find a available tag. */
-       for (tag = 0; tag < HSQ_NUM_SLOTS; tag++) {
-               slot = &hsq->slot[tag];
-               if (slot->mrq)
-                       break;
-       }
-
-       if (tag == HSQ_NUM_SLOTS)
-               tag = HSQ_INVALID_TAG;
-
+       tag = hsq->tag_slot[hsq->next_tag];
+       hsq->tag_slot[hsq->next_tag] = HSQ_INVALID_TAG;
        hsq->next_tag = tag;
 }
 

@@ -233,8 +212,14 @@ static int mmc_hsq_request(struct mmc_host *mmc, struct mmc_request *mrq)
         * Set the next tag as current request tag if no available
         * next tag.
         */
-       if (hsq->next_tag == HSQ_INVALID_TAG)
+       if (hsq->next_tag == HSQ_INVALID_TAG) {
                hsq->next_tag = tag;
+               hsq->tag_tail = tag;
+               hsq->tag_slot[hsq->tag_tail] = HSQ_INVALID_TAG;
+       } else {
+               hsq->tag_slot[hsq->tag_tail] = tag;
+               hsq->tag_tail = tag;
+       }
 
        hsq->qcnt++;
 

@@ -339,8 +324,10 @@ static const struct mmc_cqe_ops mmc_hsq_ops = {
 
 int mmc_hsq_init(struct mmc_hsq *hsq, struct mmc_host *mmc)
 {
+       int i;
        hsq->num_slots = HSQ_NUM_SLOTS;
        hsq->next_tag = HSQ_INVALID_TAG;
+       hsq->tag_tail = HSQ_INVALID_TAG;
 
        hsq->slot = devm_kcalloc(mmc_dev(mmc), hsq->num_slots,
                                 sizeof(struct hsq_slot), GFP_KERNEL);

@@ -351,6 +338,9 @@ int mmc_hsq_init(struct mmc_hsq *hsq, struct mmc_host *mmc)
        hsq->mmc->cqe_private = hsq;
        mmc->cqe_ops = &mmc_hsq_ops;
 
+       for (i = 0; i < HSQ_NUM_SLOTS; i++)
+               hsq->tag_slot[i] = HSQ_INVALID_TAG;
+
        INIT_WORK(&hsq->retry_work, mmc_hsq_retry_handler);
        spin_lock_init(&hsq->lock);
        init_waitqueue_head(&hsq->wait_queue);

drivers/mmc/host/mmc_hsq.h +5 -1

index ffdd9cd172c3..a783366285a9 100644
@@ -2,6 +2,9 @@
 #ifndef LINUX_MMC_HSQ_H
 #define LINUX_MMC_HSQ_H
 
+#define HSQ_NUM_SLOTS  64
+#define HSQ_INVALID_TAG        HSQ_NUM_SLOTS
+
 struct hsq_slot {
        struct mmc_request *mrq;
 };

@@ -17,6 +20,8 @@ struct mmc_hsq {
        int next_tag;
        int num_slots;
        int qcnt;
+       int tag_tail;
+       int tag_slot[HSQ_NUM_SLOTS];
 
        bool enabled;
        bool waiting_for_idle;
--

2.29.0

Quoted 10 lines · Michael Wu

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?

Quoted 12 lines · Wenchao Chen

Quoted 10 lines · Michael Wu

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.

Quoted 5 lines

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

(quoted diff) +0 -2

-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

Quoted 67 lines · Michael Wu

Quoted 12 lines · Wenchao Chen

Quoted 10 lines · Michael Wu

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.

Quoted 5 lines

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

(quoted diff) +0 -2

-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.

Quoted 1 line

Thank you very much for your Log. This patch can reduce latency, but I have some questions:
1. FIO -rw does not have random, but it does have randread. Do you use randread? In addition, "IO_SIZE=64M" means only 64M data is tested? Refer to FIO:
https://fio.readthedocs.io/en/latest/fio_doc.html?highlight=io_size#cmdoption-arg-io-size

2. The style of "tag_tail" should remain the same as that of "next_tag". Would "tail_tag" be better?

3. It is better to provide a comparison of sequential read, sequential write and random writeHere is the performance data tested by AndroBench:

Quoted 68 lines · Wenchao Chen

Quoted 67 lines · Michael Wu

Quoted 12 lines · Wenchao Chen

Quoted 10 lines · Michael Wu

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.

Quoted 5 lines

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

(quoted diff) +0 -2

-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.

Quoted 8 lines

Quoted 1 line

Thank you very much for your Log. This patch can reduce latency, but I have some questions:
1. FIO -rw does not have random, but it does have randread. Do you use randread? In addition, "IO_SIZE=64M" means only 64M data is tested? Refer to FIO:
https://fio.readthedocs.io/en/latest/fio_doc.html?highlight=io_size#cmdoption-arg-io-size

Hi Wenchao,

Yes, I used "randread". (Sorry, I wrote the parameter "random" incorrectly.) The reason why I used "io_size=64M" is that I found the performance of hsq was degraded when using the AndroBench for testing on android13. Therefore, fio is used to simulate the AndroBench for debugging. The AndroBench is configured with 8 threads while 1G files per thread, and only 64M data for random read testing（This item is not configurable）.

Quoted 2 lines

2. The style of "tag_tail" should remain the same as that of "next_tag". Would "tail_tag" be better?

Thank you for your suggestion. I'll modify 'tag_tail' as 'tail_tag'.

Quoted 2 lines

3. It is better to provide a comparison of sequential read, sequential write and random writeHere is the performance data tested by AndroBench:

-------------------------------------------------------------------------
io performance data from AndroBench (filesize=1G, 8 threads)
-------------------------------------------------------------------------
mmc configure | original hsq | without hsq | hsq with this patch
-------------------------------------------------------------------------
Sequential write 58.23 MB/s 51.35 MB/s 56.15 MB/s
Sequential read 138.24 MB/s 143.65 MB/s 146.4 MB/s

random write        2900.11 iops     1887.13 iops      2982.02 iops
random read         4764.45 iops     5485.19 iops      6786.42 iops

Here's a preview of patch-v2. If it's OK, I'll submit it soon. Thank you.

--
mmc:mmc-hsq:use fifo to dispatch mmc_request

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.

drivers/mmc/host/mmc_hsq.c +15 -25

index 9d35453e7371..424dc7b07858 100644
@@ -13,9 +13,6 @@
 
  #include "mmc_hsq.h"
 
-#define HSQ_NUM_SLOTS  64
-#define HSQ_INVALID_TAG        HSQ_NUM_SLOTS
-
  static void mmc_hsq_retry_handler(struct work_struct *work)
  {
        struct mmc_hsq *hsq = container_of(work, struct mmc_hsq, retry_work);

@@ -73,7 +70,6 @@ static void mmc_hsq_pump_requests(struct mmc_hsq *hsq)
 
  static void mmc_hsq_update_next_tag(struct mmc_hsq *hsq, int remains)
  {
-       struct hsq_slot *slot;
        int tag;
 
        /*

@@ -82,29 +78,12 @@ static void mmc_hsq_update_next_tag(struct mmc_hsq
 *hsq, int remains)
         */
        if (!remains) {
                hsq->next_tag = HSQ_INVALID_TAG;
+               hsq->tail_tag = HSQ_INVALID_TAG;
                return;
        }
 
-       /*
-        * Increasing the next tag and check if the corresponding request is
-        * available, if yes, then we found a candidate request.
-        */
-       if (++hsq->next_tag != HSQ_INVALID_TAG) {
-               slot = &hsq->slot[hsq->next_tag];
-               if (slot->mrq)
-                       return;
-       }
-
-       /* Othersie we should iterate all slots to find a available tag. */
-       for (tag = 0; tag < HSQ_NUM_SLOTS; tag++) {
-               slot = &hsq->slot[tag];
-               if (slot->mrq)
-                       break;
-       }
-
-       if (tag == HSQ_NUM_SLOTS)
-               tag = HSQ_INVALID_TAG;
-
+       tag = hsq->tag_slot[hsq->next_tag];
+       hsq->tag_slot[hsq->next_tag] = HSQ_INVALID_TAG;
        hsq->next_tag = tag;
  }

@@ -233,8 +212,14 @@ static int mmc_hsq_request(struct mmc_host *mmc,
 struct mmc_request *mrq)
         * Set the next tag as current request tag if no available
         * next tag.
         */
-       if (hsq->next_tag == HSQ_INVALID_TAG)
+       if (hsq->next_tag == HSQ_INVALID_TAG) {
                hsq->next_tag = tag;
+               hsq->tail_tag = tag;
+               hsq->tag_slot[hsq->tail_tag] = HSQ_INVALID_TAG;
+       } else {
+               hsq->tag_slot[hsq->tail_tag] = tag;
+               hsq->tail_tag = tag;
+       }
 
        hsq->qcnt++;

@@ -339,8 +324,10 @@ static const struct mmc_cqe_ops mmc_hsq_ops = {
 
  int mmc_hsq_init(struct mmc_hsq *hsq, struct mmc_host *mmc)
  {
+       int i;
        hsq->num_slots = HSQ_NUM_SLOTS;
        hsq->next_tag = HSQ_INVALID_TAG;
+       hsq->tail_tag = HSQ_INVALID_TAG;
 
        hsq->slot = devm_kcalloc(mmc_dev(mmc), hsq->num_slots,
                                 sizeof(struct hsq_slot), GFP_KERNEL);

@@ -351,6 +338,9 @@ int mmc_hsq_init(struct mmc_hsq *hsq, struct
 mmc_host *mmc)
        hsq->mmc->cqe_private = hsq;
        mmc->cqe_ops = &mmc_hsq_ops;
 
+       for (i = 0; i < HSQ_NUM_SLOTS; i++)
+               hsq->tag_slot[i] = HSQ_INVALID_TAG;
+
        INIT_WORK(&hsq->retry_work, mmc_hsq_retry_handler);
        spin_lock_init(&hsq->lock);

        init_waitqueue_head(&hsq->wait_queue);

drivers/mmc/host/mmc_hsq.h +5 -1

index ffdd9cd172c3..1808024fc6c5 100644
@@ -2,6 +2,9 @@
  #ifndef LINUX_MMC_HSQ_H
  #define LINUX_MMC_HSQ_H
 
+#define HSQ_NUM_SLOTS  64
+#define HSQ_INVALID_TAG        HSQ_NUM_SLOTS
+
  struct hsq_slot {
        struct mmc_request *mrq;
  };

@@ -17,6 +20,8 @@ struct mmc_hsq {
        int next_tag;
        int num_slots;
        int qcnt;
+       int tail_tag;
+       int tag_slot[HSQ_NUM_SLOTS];
 
        bool enabled;
        bool waiting_for_idle;
 
--

Regards,
Michael Wu