一次内核block层Multi queue报错IO QID timeout, reset controller案例分析

最近内核block层调试IO性能(磁盘nvme,IO调度算法bfq,内核版本centos 8.3,4.18.0-240),启动fio压测一段时间后,就发现fio莫名其妙会卡死了。一看内核日志,有如下异常打印

  • nvme nvme1: I/O 61 QID 5 timeout, aborting
  • nvme nvme1: Abort status:0x0
  • nvme nvme1: I/O 0 QID 5 timeout, reset controller

这是nvme磁盘控制器的报错信息,看着是超时了,难道fio压测把nvme盘搞挂了?因为我在IO派发流程的__blk_mq_sched_dispatch_requests->blk_mq_do_dispatch_sched->blk_mq_dispatch_rq_list流程流程的blk_mq_do_dispatch_sched函数做了一些优化,所以首先怀疑nvme控制器报timeout错误与我的代码有关。而只要blk_mq_do_dispatch_sched函数回退,再fio测试就没事了,反复验证几次都是这样。

太神奇了,难道我的代码触发了nvme控制器的bug?虽然觉得难以置信,但越是难以置信的问题,越要从最基础的知识点分析。首先看看” nvme nvme1: I/O 61 QID 5 timeout, aborting”报错是在哪里?这个很容易查到,是在nvme_timeout函数!

  1. static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
  2. {
  3.     dev_warn(dev->ctrl.device,
  4.              "I/O %d QID %d timeout, completion polled\n",
  5.              req->tag, nvmeq->qid);
  6.     dev_warn(dev->ctrl.device,
  7.              "I/O %d QID %d timeout, reset controller\n",
  8.              req->tag, nvmeq->qid);
  9.     dev_warn(nvmeq->dev->ctrl.device,
  10.         "I/O %d QID %d timeout, aborting\n",
  11.          req->tag, nvmeq->qid);
  12. }

那这个函数的触发流程是什么呢?看了一下block层IO派发流程,是这样一个流程:

首先是IO请求(简称为rq或者req)派发给磁盘控制过程,要执行blk_mq_start_request函数,启动一个IO请求超时派发定时器,代码如下:

  1. void blk_mq_start_request(struct request *rq)
  2. {
  3.     //启动rq超时派发定时器
  4.     blk_add_timer(rq);
  5.     //设置rq->state MQ_RQ_IN_FLIGHT
  6.     WRITE_ONCE(rq->state, MQ_RQ_IN_FLIGHT);
  7. }
  8. void blk_add_timer(struct request *req)
  9. {
  10.     struct request_queue *q = req->q;
  11.     unsigned long expiry;
  12.     if (!req->timeout)
  13.         req->timeout = q->rq_timeout;
  14.     req->rq_flags &= ~RQF_TIMED_OUT;
  15.     //expiryrq超时派发完成的时间点,系统jiffies时钟到expiryrq还没派发完成,就超时了
  16.     expiry = jiffies + req->timeout;
  17.     WRITE_ONCE(req->deadline, expiry);
  18.     expiry = blk_rq_timeout(round_jiffies_up(expiry));
  19.     if (!timer_pending(&q->timeout) ||
  20.         time_before(expiry, q->timeout.expires)) {
  21.         unsigned long diff = q->timeout.expires - expiry;
  22.         if (!timer_pending(&q->timeout) || (diff >= HZ / 2))
  23.             //启动timeout定时器
  24.             mod_timer(&q->timeout, expiry);
  25.     }
  26. }

定时器函数源码如下:

  1. static void blk_rq_timed_out_timer(struct timer_list *t)
  2. {
  3.     struct request_queue *q = from_timer(q, t, timeout);
  4.     //启动worker,对应函数是 blk_mq_timeout_work()
  5.     kblockd_schedule_work(&q->timeout_work);
  6. }

在定时器函数里其实就启动了q->timeout_work,它对应的函数是blk_mq_timeout_work。源码如下:

  1. static void blk_mq_timeout_work(struct work_struct *work)
  2. {
  3.     //在这里检查哪个rq超时派发了
  4.     blk_mq_queue_tag_busy_iter(q, blk_mq_check_expired, &next);
  5. }

就是在这个函数,检查哪些IO请求过了规定时间还没传输完成,源码如下:

  1. static bool blk_mq_check_expired(struct blk_mq_hw_ctx *hctx,
  2.         struct request *rq, void *priv, bool reserved)
  3. {
  4.     unsigned long *next = priv;
  5.     //如果rq在指定时间还没派发完成该if成立,执行rq超时派发完成异常处理
  6.     if (blk_mq_req_expired(rq, next))
  7.         blk_mq_rq_timed_out(rq, reserved);
  8.     return true;
  9. }
  10. static bool blk_mq_req_expired(struct request *rq, unsigned long *next)
  11. {
  12.     unsigned long deadline;
  13.     //如果rq已经派发完成了,rq->stateMQ_RQ_IN_FLIGHT改为MQ_RQ_IDLE,则这里直接返回false
  14.     if (blk_mq_rq_state(rq) != MQ_RQ_IN_FLIGHT)
  15.         return false;
  16.     if (rq->rq_flags & RQF_TIMED_OUT)
  17.         return false;
  18.     //rq->deadlinerq超时派发完成时间点,如果rqrq->deadline时间点还没派发完成,该函数返回true
  19.     deadline = READ_ONCE(rq->deadline);
  20.     if (time_after_eq(jiffies, deadline))
  21.         return true;
  22.     if (*next == 0)
  23.         *next = deadline;
  24.     else if (time_after(*next, deadline))
  25.         *next = deadline;
  26.     return false;
  27. }
  28. static void blk_mq_rq_timed_out(struct request *req, bool reserved)
  29. {
  30.     req->rq_flags |= RQF_TIMED_OUT;
  31.     if (req->q->mq_ops->timeout) {
  32.         enum blk_eh_timer_return ret;
  33.         ret = req->q->mq_ops->timeout(req, reserved);//nvme_timeout
  34.         if (ret == BLK_EH_DONE)
  35.             return;
  36.         WARN_ON_ONCE(ret != BLK_EH_RESET_TIMER);
  37.     }
  38.     blk_add_timer(req);
  39. }

如果某个IO请求在规定时间内(30s)没有传输完成,就会执行blk_mq_timeout_work-> blk_mq_check_expired-> blk_mq_rq_timed_out-> nvme_timeout 函数,报” nvme nvme1: I/O 61 QID 5 timeout, aborting”等nvme控制timeout错误。

分析到这里,因为是我在blk_mq_do_dispatch_sched()函数修改的代码导致某个IO请求超时派发完成,最终导致” nvme nvme1: I/O 61 QID 5 timeout, aborting”等nvme控制timeout错误。这个问题应该与nvme硬件没关系,是个软件问题!看下我在blk_mq_do_dispatch_sched函数修改的代码:

  1. static int blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx)
  2. {
  3.         struct request_queue *q = hctx->queue;
  4.         struct elevator_queue *e = q->elevator;
  5.         LIST_HEAD(rq_list);
  6.         int ret = 0;
  7.         int rq_count = 0;
  8.         do {   
  9.                 struct request *rq;
  10.                
  11.                 if (e->type->ops.has_work && !e->type->ops.has_work(hctx))
  12.                         break;
  13.                 if (!list_empty_careful(&hctx->dispatch)) {
  14.                         ret = -EAGAIN;
  15.                         break;
  16.                 }
  17.                 //if (!blk_mq_get_dispatch_budget(hctx))
  18.                 //        break;
  19.                 rq = e->type->ops.dispatch_request(hctx);
  20.                 if (!rq) {
  21.                         //blk_mq_put_dispatch_budget(hctx);
  22.                         blk_mq_delay_run_hw_queues(q, BLK_MQ_BUDGET_DELAY);
  23.                         break;
  24.                 }
  25.                 list_add(&rq->queuelist, &rq_list);
  26.                 rq_count++;
  27.                 if(rq_count >= 5){
  28.                     rq_count = 0;
  29.                     //当派发rq时遇到busy返回false退出while循环
  30.                     if(!blk_mq_dispatch_rq_list(q, &rq_list,false))
  31.                     {
  32.                         break;
  33.                     }
  34.                 }
  35.         //} while (blk_mq_dispatch_rq_list(q, &rq_list, true));
  36.         } while (1);
  37.        
  38.         if(!list_empty(&rq_list))
  39.             blk_mq_dispatch_rq_list(q, &rq_list, false);
  40.         return ret;
  41. }

红色是添加的代码,绿色是删除的代码。这些修改怎么会导致IO请求超时派发最终导致nvme控制器timeout报错呢?真是一个神奇的问题!调试过程很繁琐,我也始终无法理解为什么原生blk_mq_do_dispatch_sched代码为什么一次只派发一个IO请求:执行rq = e->type->ops.dispatch_request(hctx)从IO调度队列取出一个IO请求,然后while (blk_mq_dispatch_rq_list(q, &rq_list, true))这里派发这个IO请求。

为什么不能从IO队列取出多个IO请求再一次性执行blk_mq_dispatch_rq_list(q, &rq_list, true)派发多个IO请求呢(这个思路就是上边展示的blk_mq_do_dispatch_sched函数增加的红色代码的作用)?突然有了个灵感,这是因为blk_mq_dispatch_rq_list()函数只能派发同一个硬件队列的IO请求?毕竟rq = e->type->ops.dispatch_request(hctx)返回的IO请求不能预料是哪个硬件队列的!干脆rq = e->type->ops.dispatch_request(hctx)取出一个IO请求,立即执行while (blk_mq_dispatch_rq_list(q, &rq_list, true))派发。我的代码是rq = e->type->ops.dispatch_request(hctx)连续取出多个IO请求,然后再执行blk_mq_dispatch_rq_list()一次性派发这么多个IO请求。如果这些IO请求属于不同的硬件队列,就会导致nvme控制timeout异常,从而导致IO请求派发失败。

有了这个思路,在blk_mq_dispatch_rq_list函数添加调试验证一下,主要就是打印派发rq的硬件队列:

  1. bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list,                                                                                                            
  2.                              bool got_budget)
  3. {
  4.     LIST_HEAD(tmp_list);
  5.     do {
  6.         struct blk_mq_queue_data bd;
  7.         rq = list_first_entry(list, struct request, queuelist);
  8.         hctx = rq->mq_hctx;
  9.         list_del_init(&rq->queuelist);
  10.         bd.rq = rq;
  11.         if (list_empty(list))
  12.             bd.last = true;
  13.             printk("blk_mq_dispatch_rq_list:1 %s %d  bd.last:%d hctx->queue_num:%d rq:0x%llx",current->comm,current->pid,bd.last,hctx->queue_num,(u64)rq);
  14.         else {
  15.             nxt = list_first_entry(list, struct request, queuelist);
  16.             bd.last = !blk_mq_get_driver_tag(nxt);
  17.             printk("blk_mq_dispatch_rq_list:2 %s %d  bd.last:%d hctx->queue_num:%d rq:0x%llx",current->comm,current->pid,bd.last,hctx->queue_num,(u64)rq);
  18.         }
  19.         //IO请求rq派发给驱动
  20.         ret = q->mq_ops->queue_rq(hctx, &bd);
  21.         .............
  22.     } while (!list_empty(list));
  23.     ...................
  24. }

下次卡死时,打印

  • //blk_mq_dispatch_rq_list()函数中的while循环里连续派发了两个rq,但这两个rq属于不同的硬件队列
  • blk_mq_dispatch_rq_list:2 fio 35111 bq.last:0  hctx->queue_num:36  rq:0xffff9f44291f1320
  • blk_mq_dispatch_rq_list:1 fio 35111 bq.last:1  hctx->queue_num:12  rq:0xffff9f44291f30e0
  • ............
  • //30s 后触发nvme控制timeout超时报错
  • nvme nvme1: I/O 61 QID 5 timeout, aborting
  • nvme nvme1: Abort status:0x0
  • nvme nvme1: I/O 0 QID 5 timeout, reset controller

果然,blk_mq_dispatch_rq_list()函数中派发不同硬件队列的IO请求时,就会导致IO请求派发失败,30s都还没传输完成。然后就会触发” nvme nvme1: I/O 61 QID 5 timeout, aborting”报错。

为了进一步验证我的思路,在blk_mq_do_dispatch_sched()函数又做了一些调整:rq = e->type->ops.dispatch_request(hctx)取出的rq请求如果与上一个取出的rq所属不同的硬件队列,就立即执行 blk_mq_dispatch_rq_list()派发rq_list链表暂存的rq。这样保证rq_list的传递给blk_mq_dispatch_rq_list()要派发的rq都是同一个硬件队列的。果然,这样就一切正常了!完美搞定!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/587309.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

springboot(ssm中山社区医疗综合服务平台 医疗管理系统 Java系统

springboot(ssm中山社区医疗综合服务平台 医疗管理系统 Java系统 开发语言:Java 框架:ssm/springboot vue JDK版本:JDK1.8(或11) 服务器:tomcat 数据库:mysql 5.7(或8.0&#x…

使用Pytorch搭建模型

本来是只用Tenorflow的,但是因为TF有些Numpy特性并不支持,比如对数组使用列表进行切片,所以只能转战Pytorch了(pytorch是支持的)。还好Pytorch比较容易上手,几乎完美复制了Numpy的特性(但还有一…

广州市网约车平台:照片上传标准与处理技巧全解析

《广州市网络预约出租汽车综合业务管理平台》是一个旨在规范和提升广州市网约车服务质量的在线管理系统。它整合了司机和车辆信息管理、预约服务、监管监控、服务质量评价以及数据分析等功能,确保网约车服务符合当地法规要求,同时为乘客提供安全、便捷的…

React16源码: Why16, 研究源码的意义, 源码目录核心结构分析

为什么要选择React16 现在React18都早已实践很多,为何回过头来看16版本的代码理由如下 从实际出发,企业内老旧项目多为16版本,理解16的核心能够帮助我们快速解决问题16版本React是完全重写了核心代码, 是一次重大的更新 引入了 fiber 这个概…

浅谈大模型推理成本优化

上回说了,全赞AI的应用里面有用到几十个大模型,我的其他的应用比如渣渣句,熊喵表情都会或多或少的用到一到两个大模型的推理。而众所周知,目前大模型的推理存在两个问题,一个是慢,一个是贵,慢的…

MyBatisPlus之逻辑删除

系列文章目录 提示:这里可以添加系列文章的所有文章的目录,目录需要自己手动添加 MyBatisPlus之逻辑删除 提示:写完文章后,目录可以自动生成,如何生成可参考右边的帮助文档 文章目录 系列文章目录前言一、什么是逻辑删…

微服务系列之分布式事务理论

概述 事务是由一组操作构成的可靠的独立的工作单元,事务具备ACID的特性,即原子性、一致性、隔离性和持久性。 分类 大多数情况下,分类是没有意义的一件事。但是分类可以一定程度上,加深理解。 实现 从实现角度来看&#xff0…

轻松删除文件名中的符号,使用替换功能,让管理文件更加得心应手!

在我们的日常生活和工作中,文件管理是一项必不可少的任务。而一个整洁、有序的文件名系统则有助于我们快速找到所需的文件。如果你发现文件名中存在一些不必要的符号,那么这款文件重命名工具将是你的得力助手。它具备强大的替换功能,可以轻松…

数的高次幂运算取余,解决大数溢出问题

目录 解决思路引用基础数学公式公式1证明:公式2证明:公式3证明:公式4,但无法证明大数分解解决思路 当一个幂运算很大,而模为整型数时,通常的做法(先求幂再取模),结果很大可能就是数溢出,无法表示这样的大数,导致运算失败。 可以先试着将数分割成几个部分,然后一个…

在 Unity 中获取 Object 对象的编辑器对象

有这个需求的原因是,在编辑器的 Inspector 逻辑中,写了许多生成逻辑。 现在不想挨个在 Inspector 上都点一遍按钮,所以就需要能获取到它们的编辑器对象。 发现可以借助官方的 UnityEditor.Editor.CreateEditor 方法达到目的,如下…

OpcUaHelper实现西门子OPC Server数据交互

Opc ua客户端类库,基于.net 4.6.1创建,基于官方opc ua基金会跨平台库创建,方便的实现和OPC Server进行数据交互。 FormBrowseServer 在开发客户端之前,需要使用本窗口来进行查看服务器的节点状态,因为在请求服务器的节点数据之前,必须知道节点的名称,而节点的名称可以…

分布式技术之负载均衡技术

文章目录 什么是负载均衡?服务请求的负载均衡方法轮询策略随机策略哈希和一致性哈希策略对比分析 负载均衡是分布式可靠性中非常关键的一个问题或技术,在一定程度上反映了分布式系统对业务处理的能力。比如,早期的电商抢购活动,当…

4.36 构建onnx结构模型-Where

前言 构建onnx方式通常有两种: 1、通过代码转换成onnx结构,比如pytorch —> onnx 2、通过onnx 自定义结点,图,生成onnx结构 本文主要是简单学习和使用两种不同onnx结构, 下面以 Where 结点进行分析 方式 方法一…

记录一下imx6ull linux 5.10.9多点电容触摸屏驱动报错问题解决方法

最近再研究如何将linux 5.10.9移植到imx6ull,用的原子的开发板,在移植电容触摸屏驱动时报错gpio gpiochip0: (209c000.gpio): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ,如下图: 该错误的意思就是尝试将…

数据库系统概论SQL编程题合集(包含期末题、考研初试题以及复试题)

二、现有数据库casemanage中表结构如下图 1)请编写sql语句对年龄进行升序排列 select * from afinfo order by birth;2)请编写sql语句查询对“徐”姓开头的人员名单 select * from afinfo where name like 徐%;3)请编写sql语句修改“陈晓”…

【在大厂做测试外包这一年】

​ 在大厂做测试外包这一年 大厂外包是一种趋势,以后可能会越来越多,最起码测试行业是这样,像我们的测试工作,我所在的项目领导是大厂内部的,组长是OD外包,组员是普通外包。   1、关于办公方式 有两种方…

2024年【茶艺师(初级)】考试技巧及茶艺师(初级)试题及解析

题库来源:安全生产模拟考试一点通公众号小程序 茶艺师(初级)考试技巧是安全生产模拟考试一点通生成的,茶艺师(初级)证模拟考试题库是根据茶艺师(初级)最新版教材汇编出茶艺师&#…

「Kafka」入门篇

「Kafka」入门篇 基础架构 Kafka 快速入门 集群规划 集群部署 官方下载地址:http://kafka.apache.org/downloads.html 解压安装包: [atguiguhadoop102 software]$ tar -zxvf kafka_2.12-3.0.0.tgz -C /opt/module/修改解压后的文件名称: [a…

Vue3使用WangEditor编辑器

WangEditor的基本使用&#xff0c;图片上传功能 没详细讲解&#xff0c;只是做个记录。 Componets 下定义 WangEditor.vue 文件 <template><div style"border: 1px solid #ccc;"><Toolbar style"border-bottom: 1px solid #ccc" :editor&q…

关于HTTPS

目录 什么是加密 对称加密 非对称加密 中间人攻击 引入证书 HTTPS是一个应用层的协议,是在HTTP协议的基础上引入了一个加密层. HTTP协议内容都是按照文本的方式明文传输,这就导致在传输的过程中出现一些被篡改的情况. 运营商劫持事件 未被劫持的效果,点击下载按钮,就会…