【OLK-5.10】fix performance in blk-mq due to fair share of driver tag

#### unfair dtag 原理

##### 共享tag原理

scsi中blk_mq_tag_set是在Scsi_Host下的：

```c
struct Scsi_Host {
......

/* Area to keep a shared tag map */
        struct blk_mq_tag_set   tag_set;
......
};
```

host下的盘初始化q使用的都是相同的tag_set，也就是意味着同一个host下的所有盘将共享tag

```c
struct request_queue *scsi_mq_alloc_queue(struct scsi_device *sdev)
{
        sdev->request_queue = blk_mq_init_queue(&sdev->host->tag_set);
        if (IS_ERR(sdev->request_queue))
                return NULL;
}
```

当有多块盘共享tag时，每块盘能拿到的tag数量是fair_share：平分总tag

```c
/*
 * For shared tag users, we track the number of currently active users
 * and attempt to provide a fair share of the tag depth for each of them.
 */
static inline bool hctx_may_queue(struct blk_mq_hw_ctx *hctx,
                                ┊ struct sbitmap_queue *bt)
   -> 改接口返回true表示可以拿tag，否则io无法下发
{
        unsigned int depth, users;

if (!hctx || !(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED))
        -> 只有共享tag场景涉及
                return true;

/*
        ┊* Don't try dividing an ant
        ┊*/
        if (bt->sb.depth == 1)
        -> 总tag数量为1时，不考虑平分
                return true;

if (blk_mq_is_sbitmap_shared(hctx->flags)) {
                struct request_queue *q = hctx->queue;
                struct blk_mq_tag_set *set = q->tag_set;

if (!test_bit(QUEUE_FLAG_HCTX_ACTIVE, &q->queue_flags))
                        return true;
                users = atomic_read(&set->active_queues_shared_sbitmap);
        } else {
                if (!test_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state))
                        return true;
                users = atomic_read(&hctx->tags->active_queues);
        }

if (!users)
        -> users代表正在共享tag的设备中，有io的设备数量
                return true;

/*
        ┊* Allow at least some tags
        ┊*/
        depth = max((bt->sb.depth + users - 1) / users, 4U);
        -> depth 代表平分后一个盘能拿到的tag数量
        
        return __blk_mq_active_requests(hctx) < depth;
        -> 最后比较已下发的io数量和平分到的tag数量
}
```

##### 共享tag的问题

特定场景存在性能问题：

假设一共有128个tag，8个设备平分，每个设备只能分到16个，

如果其中7个设备之下了1个io，理论上还有121个tag空闲，但是第8个设备只能并发下发16个io

##### unfair_dtag 改动

1. 新增引用计数pending_queues，只有拿tag失败后才增加
2. 当pending_queues为0时，拿tag不做限制；当pending_queues大于0时，回退到平分tag
3. pending_queues一旦设上，每隔5s清掉

[TOC]

#### 功能测试

##### 测试环境

x86虚拟机，host0下有8块scsi盘：

```shell
[root@localhost ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  100G  0 disk
sdb      8:16   0   15G  0 disk
sdc      8:32   0   10G  0 disk
sdd      8:48   0   10G  0 disk
sde      8:64   0   10G  0 disk
sdf      8:80   0   10G  0 disk
sdg      8:96   0   10G  0 disk
sdh      8:112  0   10G  0 disk
vda    253:0    0    6G  0 disk
└─vda1 253:1    0    6G  0 part /
vdb    253:16   0   20G  0 disk
pmem0  259:0    0   16G  0 disk
pmem1  259:1    0   16G  0 disk
```

tag总数量128：

```shell
[root@localhost unfair_dtag]# cat /sys/class/scsi_host/host0/can_queue
128
```

因为5.10存在两种共享方式：

- 硬件队列共享：virtio-scsi 默认方式

- request_queue共享：需要修改内核才能让virtio-scsi使能：

```c
  diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
  index fabbad5cda60..e8d6f85eb8a4 100644
  --- a/drivers/scsi/virtio_scsi.c
  +++ b/drivers/scsi/virtio_scsi.c
  @@ -755,6 +755,7 @@ static struct scsi_host_template virtscsi_host_template = {
          .dma_boundary = UINT_MAX,
          .map_queues = virtscsi_map_queues,
          .track_queue_depth = 1,
  +       .host_tagset = 1,
   };
  ```

##### 功能测试 fio 命令：

其中，sd[abcdefg]只下一个io，sdh并发下121个io

```shell
[global]
ioengine=libaio
direct=1
time_based
runtime=60
rw=randwrite
bs=4k

[sda]
filename=/dev/sda
numjobs=1
iodepth=1
[sdb]
filename=/dev/sdb
numjobs=1
iodepth=1
[sdc]
filename=/dev/sdc
numjobs=1
iodepth=1
[sdd]
filename=/dev/sdd
numjobs=1
iodepth=1
[sde]
filename=/dev/sde
numjobs=1
iodepth=1
[sdf]
filename=/dev/sdf
numjobs=1
iodepth=1
[sdg]
filename=/dev/sdg
numjobs=1
iodepth=1
[sdh]
filename=/dev/sdh
numjobs=11
iodepth=11
```

##### 测试结果：

使用命令while true; do cat /sys/block/sd[abcdefgh]/inflight; sleep 0.5 ; echo "------------"; done查看每个盘的inflight io情况

合入补丁前：sdh io并发数量最高只能达到16

```shell
------------
       0        1
       0        0
       0        0
       0        0
       0        1
       0        0
       0        1
       0       11
------------
       0        1
       0        0
       0        0
       0        1
       0        1
       0        1
       0        1
       0       16
------------
       0        0
       0        1
       0        0
       0        0
       0        0
       0        0
       0        1
       0        9
------------
       0        1
       0        0
       0        1
       0        0
       0        1
       0        1
       0        1
       0        1
------------
       0        0
       0        1
       0        0
       0        1
       0        0
       0        0
       0        0
       0       15
```

合入补丁后：sdh io并发数量能达到121

```shell
------------
       0        1
       0        1
       0        1
       0        1
       0        1
       0        1
       0        1
       0      121
------------
       0        1
       0        1
       0        1
       0        1
       0        1
       0        1
       0        1
       0      117
------------
       0        1
       0        1
       0        1
       0        1
       0        1
       0        1
       0        1
       0      114
```

#### 性能测试

因为修改了通用块层的逻辑，增加了一些流程，这里使用null_blk测试，高并发场景下打上补丁后iops是否有劣化

##### 测试命令

```
fio -filename=/dev/nullb0 -name=test -ioengine=io_uring -direct=1
-numjobs=32 -iodepth=32 -bs=4k -rw=write -group_reporting -runtime=30
--thread --gtod_reduce=1 --ioscheduler=none -time_based
```

##### 测试结果

| test round | with this patch | without this patch |
| ---------- | --------------- | ------------------ |
| 1          | 4310k           | 4265k              |
| 2          | 4295k           | 4327k              |
| 3          | 4217k           | 4213k              |
| 4          | 4355k           | 4236k              |
| 5          | 4315k           | 4337k              |
| average    | 4294k           | 4275k              |

GVP openEuler/kernel

内容风险标识

评论 (1)

GVPopenEuler/kernel

内容风险标识