Hi mazhenxian, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers.

抓一下4.18和5.10 的火焰图，另外5.10使用mount -odioread_lock后再对比一下写性能是否有提升。这是4.18->5.10 ext4 dio性能的一个已知差异

火焰图
4.18
5.10

nice:0

nice:10

ps: perf 抓的指定cpu 10

nice:0

nice:10

ps : perf 抓的fio进程

初步看，5.x的ext4 DIO框架改成iomap后，kworker-dio的任务唤醒次数任务调度频繁，导致cpu上下文切换消耗增加。

cat /sys/block/nvme0n1/queue/rq_affinity 这个值是多少
可以试试 echo 0 > /sys/block/nvme0n1/queue/rq_affinity 后看看有没有性能提升

对于下面这段workqueue的实现代码

static int worker_thread(void *__worker)
{
   do {
     ...
     process_one_work
     ...
   } while (keep_working(pool));

   ...
sleep:
  schedule();
  goto woke_up;
}

能否抓一下dio下发相同size（不是time_based，保证完成次数相同，也即process_work的调用次数相同场景下）后，5.10和4.18 的后台dio kworker 分别schedule执行了多少次。

根据火焰图，我猜5.10会执行的更多一些。导致后台worker抢占更多CPU使用率。

对比4.18和5.10 ext4 dio 完成流程，5.10的end_io实现更少（只有一条isize判断语句），理论执行速度更快。由于fio和kworker的优先级一样，基于CFS调度两个任务执行的时间片应该是相同的，因此5.10 worker在做完process_one_work（ext4_dio_write_end_io）后有更多机会做schedule，导致了schedule带来的CPU使用率(因此增加worker的nice值可以减少worker的schedule频率，让前台fio有更多CPU)

4.18
ext4_end_io_dio
 ext4_put_io_end
  ext4_release_io_end
   ext4_finish_bio

5.10
ext4_dio_write_end_io
 if (pos > i_size_read(inode))

ext4 dio end io的流程变更是由引入

378f32bab3714f04c4e0c3aee4129f6703805550 (ext4 dio切换iomap)
5899593f51e63dde2f07c67358bd65a641585abb (Fix补丁)

我们尝试了使用unbound模式使用kworker，可以实现打散kworker来避免与fio的cpu争抢。改动如下：

diff --git a/fs/direct-io.c b/fs/direct-io.c
index 9dafbb07dd6a..cb056cd21d30 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -577,7 +577,7 @@ int sb_init_dio_done_wq(struct super_block *sb)
 {
        struct workqueue_struct *old;
        struct workqueue_struct *wq = alloc_workqueue("dio/%s",
-                                                     WQ_MEM_RECLAIM, 0,
+                                                     WQ_MEM_RECLAIM | WQ_UNBOUND, 0,
                                                      sb->s_id);
        if (!wq)
                return -ENOMEM;

但是在测试中发现下面几种情况，性能可以提高，但是不稳定，具体的：

• 在开numa机器中性能可以提高，且较为稳定，iops大概可以从220k提高到250k，但与4.18仍存在月10K的差距；
• 在关numa机器中，性能也可以提高，但是不稳定。iops在200-270k中间浮动，且浮动范围较大。
  原因怀疑在关numa中，dio与fio存在跨numa访问，存在性能损失。且kworker漂移到其他cpu，与cpu affinity也有关系。
  请问是否有其他较好解决方案？

5.10,unbound模式，设置cpumask
https://gitee.com/mazhenxian/test/blob/master/perf.svg

问题原因：ext4切换iomap后（378f32bab3714f04c4e0c3aee4129f6703805550），aio dio覆盖写场景的完成由 中断上下文处理 变成了 基于workqueue启worker处理，因为多了唤醒kworker的流程并且kworker和fio在同一CPU会竞争计算资源，处理路径相比4.18效率低，表现为IO完成速度慢：
4.18

dio_bio_end_aio
 defer_completion = dio->defer_completion || (dio->op == REQ_OP_WRITE && dio->inode->i_mapping->nrpages); // 只有fio -sync或者ext4写入unwritten ext区域才会走kworker路径（详见ext4_dio_get_block_unwritten_async中设置set_buffer_defer_completion 和 get_more_blocks中基于buffer_defer_completion设置dio->defer_completion）
 if (defer_completion) {
    queue_work(dio->inode->i_sb->s_dio_done_wq, &dio->complete_work);
 } else {
    dio_complete(dio, 0, DIO_COMPLETE_ASYNC); // 中断上下文完成DIO
 }

5.10

iomap_dio_bio_end_io
 if (dio->wait_for_completion) { // 非aio场景
 } else if (dio->flags & IOMAP_DIO_WRITE) {
    queue_work(inode->i_sb->s_dio_done_wq, &dio->aio.work); // aio场景默认都是kworker完成DIO
 } else {
    iomap_dio_complete_work(&dio->aio.work);
 }

对于fio测试，2G文件在nvme可以很快（<2s）完成一次全覆盖写（unwritten -> written），之后的测试都是overwrite。对于4.18都是在nvme irq中完成DIO，对于5.10则是使用kworker完成DIO。由于外部厂商使用的nvme硬件队列数量和CPU数量相同，因此每当DIO完成都会在下发的CPU上处理nvme中断，意味着fio、nvme irq、kworker（5.10）在同一个CPU上执行。5.10使用单独kworker处理DIO完成，nvme irq完成会先唤醒worker，然后worker处理DIO，并且fio和kworker会在同一CPU竞争资源，相比4.18直接在nvme irq完成DIO 5.10效率会降低，因此性能会差。

可以解释之前观测到的现象：
4.18很难抓到dio kworker：只有第一次写才会用kworker处理，后续相同地址的写都是nvme irq完成，因此kworker很难看到。
火焰图中5.10 kworker的schedule占比很高：由于5.10 DIO完成只有一条语句，执行很快，导致kworker大部分时间都在做schedule
修改5.10 kworker nice值可以提升性能：fio和kworker会抢CPU，kworker实际执行时间很短，调低kworker优先级一定程度可以提升fio下发速度

当前linux主线代码和5.10逻辑一样，也存在类似问题。

linux主线修复方法已发社区（不一定被社区接受，kworker完成DIO还有一个原因是要invalidate pages，我把invalidate操作删除了）：https://lore.kernel.org/linux-ext4/20240229113849.2222577-1-chengzhihao1@huawei.com/T/#t

OLK 适配补丁（本地物理机测试 效果960MiB/s -> 1372MiB/s）
!4820: ext4: dio: Put endio under irq context for overwrite

5.10与4.18在mysql压测场景下，sysbench 32线程时，perf采集的火焰图链接与diff文件，在文件夹20240311中
https://gitee.com/mazhenxian/test/tree/master/20240311