阻塞在io_schedule里

最新推荐文章于 2024-03-24 14:28:17 发布
最新推荐文章于 2024-03-24 14:28:17 发布
阅读量6.9k 收藏 6
点赞数
CC 4.0 BY-SA版权
文章标签： io buffer thread android kill file
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/fei1700/article/details/6573861
在Android系统中遇到fsck_msdos进程因插拔存储卡而陷入D状态的问题，研究发现进程卡在sync_page的io_schedule，由于页锁导致进程无法继续。分析了同步页面、解锁流程以及块设备驱动的行为，揭示了在插拔过程中由于队列停止导致的请求未处理，使得某些页保持锁定状态，从而难以终止进程。解决方案在于移除队列中的请求以解锁页面。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

最近碰到一个问题，android平台，在执行fsck_msdos时拔卡，出现fsck_msdos进程状态为D。因为卡驱动插拔部分(非MMC那一套)我已经改成如果没有umount就不再进行新一轮的插卡检测，所以这里就不能正常跑了

 

1. 查看该进程堆栈 cat /proc/pid/stack

    看到停在sync_page里的io_schedule。单独看到io_schedule我以为和schedule差不多，往里看并没有设置进程状态为非RUNNING, 所以以为与schedule一样会得到再次调度，实际上io_schedule是需要唤醒的。wait_on_page_bit有将进程状态设置为TASK_UNINTERRUPTIBLE，再调用sync_page。

2. 阻塞在sync_page的io_schedule是因为page状态为lock。每个page操作期间都会上锁，如果此时状态为lock，就是同样的page被另一个进程正在访问，但ps查看所有进程并没有什么进程被阻塞，连底层card_queue_thread也是sleep状态。

3. 结果我花时间把ULK 相关3章看了一遍，还是没头绪，总认为是kernel本身的问题，认为可能是插拔这种非正常状态下导致某些路径未执行unlock_page解锁。花了好长时间在这个上面，加了无数打印看流程

4. 我的打印集中在block_read_full_page，

如果uptodate的就直接end_buffer_async_read，否则submit_bh->sumbit_bio到底层

对于page都是uptodate马上unlock。e

最低0.47元/天 解锁文章

200万优质内容无限畅学
fei1700
关注
了解 Linux I/O 调度（Linux I/O Scheduler）算法
LU_ZHAO的博客
03-22 1205
查看io调度算法： :dmesg | grep -i scheduler [ 0.571636] io scheduler noop registered [ 0.571637] io scheduler deadline registered [ 0.571654] io scheduler cfq registered (default) 查看使用的io调度算法： :ll ...
如何评价Netty封装的io_uring？
BUG_zhentan的博客
08-09 1404
linux AIO 简史 在继续 io_uring 的旅行之前，让我们先回顾一下 linux 中的各种异步 IO，也就是 AIO。 1. glibc aio 官方地址：Perform I/O Operations in Parallel（官方文档用的字眼比较考究） glibc 是 GNU 发布的 libc 库，该库提供的异步 IO 被称为 glibc aio，在某些地方也被称为 posix aio。glibc aio 用多线程同步 IO 来模拟异步 IO，回调函数在一个单线程中执行。 该实现备受非
Linux IO Scheduler（Linux IO 调度器）
weixin_34179968的博客
04-14 183
     每个块设备或者块设备的分区，都对应有自身的请求队列(request_queue),而每个请求队列都可以选择一个I/O调度器来协调所递交的request。I/O调度器的基本目的是将请求按照它们对应在块设备上的扇区号进行排列，以减少磁头的移动，提高效率。每个设备的请求队列里的请求将按顺序被响应。实际上，除了这个队列，每个调度器自身都维护有不同数量的队列，用来对递交上来的request进行处理...
Linux kernel探究IO Scheduling
Gtlions Tracker
04-03 1388
为什么我们需要调整磁盘I/O scheduling算法？在什么情况下我们需要考虑调整调度算法？该如何调整？本文将针对上述问题做些回答。 I/O scheduling是操作系统存取数据块顺序的算法规则总称，某些情况下我们可能更熟悉称它为 disk scheduling。 出于以下几个目我们可能会需要考虑调整磁盘的调度算法： 最小化磁盘寻道时间； 优化关键进程的I/O请求，保证关键进程的I/O
Boost.ASIO源码：deadline_timer源码级解析（三）—— 从源码解释io_service::run()到底发生了什么
weixin_43827934的博客
12-26 1680
上一篇博客讲到了epoll_reactor的scheduler_timer函数，但是这个函数的操作逻辑其实很不明显，后面涉及到更深的逻辑，故在这里展开讲解。 其实这篇文章的主题我也纠结了很久，不知道从何讲起，因为这个逻辑牵扯十分的深，整个io_service的运行逻辑几乎都有牵扯到，于是干脆就借此总结下io_service.run()的大致运行逻辑。 前文回顾 前面讲deadline_timer:...
android 系统优化时 systrace 中 "wait_on_page_locked_killable " 阻塞过长
qkhhyga2016的博客
03-13 5191
systrace 中 “wait_on_page_locked_killable ” 阻塞过长 wait_on_page_locked_killable 在 systrace 上的提示是 IO block, 那到底是怎么阻塞法? 阻塞在谁那? 下面经代码(kernel 4.4 linux 内核版本)分析来找出答案. 我先列出该函数的调用流程,如下图所示  wait_on_page_l...
Ioctl命令组成、阻塞IO实现、IO多路复用 >>Linux设备驱动程序
学习带来的愉悦具有很高的延迟，但还在承受范围内
12-25 1242
我又来了，一天学习一点点，一天成长一点点就会很开心的说！ 今天的状态很好，况且还有好喝的咖啡陪伴着我，元气满满哟！^. ^? 文章目录[0x100]内容概述[0x200] 编写ioctl的命令编号[0x210]命令编号组成[0x220]创建命令编号[0x230]这里有个例子[0x300] 阻塞IO与休眠[0x310] 产生休眠的必要条件[0x311]休眠宏接口[0x312]唤醒宏接口[0x31...
记一次由PCI BAR配置不正确引发的硬盘IO调度io_schedule阻塞的经历
李迟的专栏
05-08 2757
五一前，接到一个bug，大意是说设备接固态硬盘时跑新内核会出现卡死导致WDT复位，使用旧内核没问题。新内核是去年年底别人编译的，旧内核是3年前现在已离职2年的人编译的，现在安排我解决这个问题。但其时正在进行其他部门的紧急测试任务，于是请求节后解决。我最近的计划是学习以太网驱动，而五一没什么计划就去看了，本来想研究SCSI的，但先等查问题后再说吧。
Linux进程调度时机 Schedule函数解析
11-16
Linux进程调度时机 Schedule函数解析
linux io schedule: CFQ
cosmoslhf的专栏
11-14 4027
CFQ，即Completely Fair Queueing绝对公平调度器，力图为竞争块设备使用权的所有进程分配一个等同的时间片，在调度器分配给进程的时间片内，进程可以将其读写请求发送给底层块设备，当进程的时间片消耗完，进程的请求队列将被挂起，等待调度。相对于Noop和Deadline调度器，CFQ要复杂得多，因此可能要分几次才能将其分析完。   优先级       每个进程都会有一个IO优先
【随笔】配置Linux IO scheduler算法
厚积薄发者，轻舟万重山
01-07 873
一、概述 Unix操作系统从一开始就将设备看作文件，纳入文件系统的范畴，允许通过文件系统接口来访问设备。 厂商的设备驱动程序是一个ko文件，Linux将其视为一个内核模块，可以通过insmod指令手动加载到内核中；现代Linux进一步抽象了设备驱动模型能做到自动加载和热插拔，主要依赖于 二、运行时修改（临时修改） 三、通过启动时内核参数修改 参考资料 《understanding the linux kernel 3rd》 https://rollout.io/blog/linux-io.
Linux进程核心调度器之主调度器schedule--Linux进程的管理与调度(十九）
热门推荐
OSKernelLAB(gatieme)
07-10 1万+
日期 内核版本 架构 作者 GitHub 优快云 2016-06-30 Linux-4.6 X86 & arm gatieme LinuxDeviceDrivers Linux进程管理与调度 我们前面提到linux有两种方法激活调度器：核心调度器和 一种是直接的, 比如进程打算睡眠或出于其他原因放弃CPU 另一种是通过周期性的机制, 以固定的频率运行, 不
IO调度器详解（1）
phmatthaus的专栏
03-24 276
IO调度器详解（1）
Linux Kernel Complete
寒霜落叶YIO的博客
11-28 1080
Linux Kernel Complete实现详细解析
Iowait的成因、对系统影响及对策
weixin_34341229的博客
11-15 1138
什么是iowait？顾名思义，就是系统因为io导致的进程wait。再深一点讲就是：这时候系统在做io，导致没有进程在干活，cpu在执行idle进程空转，所以说iowait的产生要满足两个条件，一是进程在等io，二是等io时没有进程可运行。 Iowait是如何计算的？先说说用户如何看到iowait吧我们通常用vmstat就能看到iowat，图中的wa就是（标红）这个数据是vmstat经过计算文件/...
Linux mmc驱动框架(4)——卡检测及初始化
深海
02-25 2839
Linux mmc驱动框架卡检测函数`mmc_rescan``mmc_rescan->mmc_rescan_try_freq`SDIO卡`mmc_rescan->mmc_rescan_try_freq->mmc_attach_sdio`SD卡`mmc_rescan->mmc_rescan_try_freq->mmc_attach_sd`MMC卡`mmc_rescan-...
mNetworkRefreshDisposable = Observable.timer(delay, TimeUnit.SECONDS) .flatMap { mNetworkRepository.refreshNetwork(getApplication(), true) } .doFinally { mNetworkRefreshedEvent.postValue(true) trackNetworkEvent() } .flatMap { refreshTMPData() } .retryWhen { it.flatMap { t -> TLog.d("TestPon", "t :") if (isNetworkConnectionException(t)) { Observable.error(t) } else { Observable.just(true).delay(DEFAULT_REFRESH_DATA_SCHEDULE_TIME - delay, TimeUnit.SECONDS) } } } .repeatWhen { it.delay(DEFAULT_REFRESH_DATA_SCHEDULE_TIME - delay, TimeUnit.SECONDS) } .doOnSubscribe { mNetworkRefreshedEvent.postValue(false) } .subscribeOn(Schedulers.io()) .subscribe() } retrywhen里面的逻辑是哪里的
最新发布
06-12
<think>嗯，用户这次聚焦在RxJava的retryWhen操作符上，看来是遇到了网络请求重试逻辑的具体实现问题。用户引用了四篇站内文档，其中引用[1]和[4]直接提到了retryWhen在错误重试机制中的应用，引用[2]则强调了RxJava在物联网场景处理异步事件的能力，这些正好能支撑解释retryWhen的核心价值。用户可能正在开发需要健壮网络请求的功能，比如移动端APP的登录模块或物联网设备通信层。ta特意提到“处理网络异常时的应用场景”，暗示需要实用案例而非纯理论，这点从ta引用的token机制（引用[1]第五条）和验证码功能（引用[1]第十四条）也能印证。深层需求可能是想解决自家项目中的网络抖动问题，同时避免粗暴的固定次数重试。retryWhen的难点在于理解其响应式重试机制——不是被动捕获异常，而是将异常事件转化为新的数据流决策。需要重点说明三点：1）如何用Func1函数将Throwable转化为重试触发器；2）为什么建议配合指数退避（引用[4]提到这个算法）；3）内存泄漏风险（引用[13]提到过）。用户引用的资料里，引用[4]关于.repeatWhen()/.retryWhen()的思考文档最相关，但要注意它的示例代码用了较旧的timer()操作符，按引用[3]的说明现在应改用interval()。对比用户引用的资料，发现有个关键细节：引用[1]的第六点“错误重试机制”和引用[4]都讨论了retryWhen，但用户没提repeatWhen。需要明确区分这两个操作符，避免用户混淆——retryWhen在onError时触发，而repeatWhen在onCompleted时触发，这点在源码设计上差异很大（retryWhen继承自RetryWhenHandler，repeatWhen则用RepeatWhenHandler）。最后要注意技术细节的准确性。比如引用[3]提到RxJava3移除了AndroidSchedulers.mainThread()的泄漏修复逻辑，那么在实现延迟重试时，若切主线程需自行处理Handler泄漏（虽然用户没直接问，但代码示例里写Schdulers.io()就能规避这个问题）。</think> RxJava的`retryWhen`操作符是实现**智能错误重试机制**的核心工具，尤其在处理网络请求等不稳定性操作时至关重要。以下从逻辑原理、源码实现和应用场景三个层面详细解析： --- ### 一、操作逻辑原理 `retryWhen`的核心思想：**将原始流的异常事件转化为一个决定是否重试的决策流**。 其工作流程如下： 1. **监听异常**：当上游数据流抛出`Throwable`异常（如`IOException`）时，`retryWhen`捕获该异常 2. **生成决策流**：通过传入的`Func1<Observable<Throwable>, Observable<?>>`函数，将异常序列转化为新的“决策流” 3. **决策重试**： - 若决策流发送`onNext`事件（任意值），则重新订阅原始流（**重试**） - 若决策流发送`onError`/`onCompleted`事件，则终止流程（**不再重试**） ```java // 伪代码逻辑 sourceObservable .retryWhen(errors -> errors.flatMap(error -> { if (isRetryable(error)) { return Observable.timer(2, SECONDS); // 2秒后发送onNext触发重试 } else { return Observable.error(error); // 终止流程 } }) ); ``` --- ### 二、源码实现关键细节 1. **异常事件转换** 源码通过`OperatorRetryWithPredicate`（内部类）将上游异常事件投射到一个新Observable： ```java public void onError(Throwable e) { // 将异常发送给"决策流"生成函数 Observable<?> resume = handler.call(notificationHandler); // 监听决策流的结果 resume.subscribe(new InnerSubscriber()); } ``` 2. **重试控制** 决策流的`onNext`会触发`innerSubscription`重新订阅原始Observable： ```java if (value == NotificationLite.INSTANCE) { innerSubscription = subscribeToSource(); // 重新订阅核心方法 } ``` 3. **终止条件** 决策流若发出`onCompleted/onError`，则直接向下游传递对应事件，**结束重试循环**。 --- ### 三、网络异常处理的核心应用 #### 典型场景：指数退避重试（Exponential Backoff） ```java .retryWhen(errors -> errors .zipWith(Observable.range(1, MAX_RETRIES), (error, retryCount) -> retryCount) .flatMap(retryCount -> (retryCount > MAX_RETRIES) ? Observable.error(error) // 超过最大重试次数则失败 : Observable.timer((long) Math.pow(2, retryCount), SECONDS) // 指数延迟 ) ); ``` **优势**： ✅ 避免固定间隔重试对服务器的瞬时冲击 ✅ 根据重试次数动态延长等待时间（如 2s → 4s → 8s） ✅ 可控最大重试次数防止无限循环 #### 进阶场景：Token失效刷新后重试 结合`flatMap`实现凭证自动更新（引用[1]第五条的优化）： ```java .retryWhen(errors -> errors.flatMap(error -> { if (error instanceof TokenExpiredException) { return refreshToken().flatMap(token -> Observable.just(token).delay(1, SECONDS) // 刷新后延迟重试 ); } return Observable.error(error); })); ``` --- ### 四、注意事项 1. **内存泄漏风险** 重试过程持有外部类引用时，需配合RxLifecycle或`CompositeDisposable`管理订阅 2. **线程切换** 建议在决策流中指定`observeOn(Schedulers.io())`，避免阻塞UI线程 （引用[3]中RemoteScheduler适用于跨进程场景） 3. **不可恢复错误** 需明确过滤非重试型异常（如`AuthenticationFailException`直接终止流程） ---
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值