请教linux下用户态进程调度问题

如题所述

 在进行Linux系统操作的时候,有时候会遇到一次用户态进程死循环,即系统反应迟钝、进程挂死等问题,那么遇到这些问题又该如何解决呢?下面小编就给大家介绍下一次用户态进程死循环的问题该如何处理。
Linux下如何处理一次用户态进程死循环问题
  1、问题现象
  业务进程(用户态多线程程序)挂死,操作系统反应迟钝,系统日志没有任何异常。从进程的内核态堆栈看,看似所有线程都卡在了内核态的如下堆栈流程中:
  [root@vmc116 ~]# cat /proc/27007/task/11825/stack
  [《ffffffff8100baf6》] retint_careful+0x14/0x32
  [《ffffffffffffffff》] 0xffffffffffffffff
  2、问题分析
  1)内核堆栈分析
  从内核堆栈看,所有进程都阻塞在 retint_careful上,这个是中断返回过程中的流程,代码(汇编)如下:
  entry_64.S
  代码如下:
  ret_from_intr:
  DISABLE_INTERRUPTS(CLBR_NONE)
  TRACE_IRQS_OFF
  decl PER_CPU_VAR(irq_count)
  /* Restore saved previous stack */
  popq %rsi
  CFI_DEF_CFA rsi,SS+8-RBP /* reg/off reset after def_cfa_expr */
  leaq ARGOFFSET-RBP(%rsi), %rsp
  CFI_DEF_CFA_REGISTER rsp
  CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
  。。。
  retint_careful:
  CFI_RESTORE_STATE
  bt $TIF_NEED_RESCHED,%edx
  jnc retint_signal
  TRACE_IRQS_ON
  ENABLE_INTERRUPTS(CLBR_NONE)
  pushq_cfi %rdi
  SCHEDULE_USER
  popq_cfi %rdi
  GET_THREAD_INFO(%rcx)
  DISABLE_INTERRUPTS(CLBR_NONE)
  TRACE_IRQS_OFF
  jmp retint_check
  这其实是用户态进程在用户态被中断打断后,从中断返回的流程,结合retint_careful+0x14/0x32,进行反汇编,可以确认阻塞的点其实就在
  SCHEDULE_USER
  这其实就是调用schedule()进行调度,也就是说当进程走到中断返回的流程中时,发现需要调度(设置了TIF_NEED_RESCHED),于是在这里发生了调度。
  有一个疑问:为什么在堆栈中看不到schedule()这一级的栈帧呢?
  因为这里是汇编直接调用的,没有进行相关栈帧压栈和上下文保存操作。
  2)进行状态信息分析
  从top命令结果看,相关线程实际一直处于R状态,CPU几乎完全耗尽,而且绝大部分都消耗在用户态:
  [root@vmc116 ~]# top
  top - 09:42:23 up 16 days, 2:21, 23 users, load average: 84.08, 84.30, 83.62
  Tasks: 1037 total, 85 running, 952 sleeping, 0 stopped, 0 zombie
  Cpu(s): 97.6%us, 2.2%sy, 0.2%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
  Mem: 32878852k total, 32315464k used, 563388k free, 374152k buffers
  Swap: 35110904k total, 38644k used, 35072260k free, 28852536k cached
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
  27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
  27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
  27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
  27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
  27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
  25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
  30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
  13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
  16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
  6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
  27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
  27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
  27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
  27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
  27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
  27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
  。。。
  3)进程调度信息
  从相关线程的调度信息看:
  [root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
  15681811525768 129628804592612 3557465
  [root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
  15682016493013 129630684625241 3557509
  [root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
  15682843570331 129638127548315 3557686
  [root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
  15683323640217 129642447477861 3557793
  [root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
  15683698477621 129645817640726 3557875
  发现相关线程的调度统计一直在增加,说明相关线程一直是在被调度运行的,结合其状态也一直是R,推测很可能在用户态发生了死循环(或者非睡眠死锁)。
  这里又有问题:为什么从top看每个线程的CPU占用率只有10%左右,而不是通常看到的死循环进程导致的100%的占用率?
  因为线程数很多,而且优先级都一样,根据CFS调度算法,会平均分配时间片,不会让其中一个线程独占CPU。结果为多个线程间轮流调度,消耗掉了所有的cpu。。
  另一个问题:为什么这种情况下,内核没有检测到softlockup?
  因为业务进程的优先级不高,不会影响watchdog内核线程(最高优先级的实时线程)的调度,所以不会产生softlockup的情况。
  再一个问题:为什么每次查看线程堆栈时,总是阻塞在retint_careful,而不是其它地方?
  因为这里(中断返回的时候)正是调度的时机点,在其它时间点不能发生调度(不考虑其它情况~),而我们查看线程堆栈的行为,也必须依赖于进程调度,所以我们每次查看堆栈时,正是查看堆栈的进程(cat命令)得到调度的时候,这时正是中断返回的时候,所以正好看到的阻塞点为retint_careful。
  4)用户态分析
  从上面的分析看,推测应该是用户态发生了死锁。
  用户态确认方法:
  部署debug信息,然后gdb attach相关进程,确认堆栈,并结合代码逻辑分析。
  最终确认该问题确为用户态进程中产生了死循环。
温馨提示:内容为网友见解,仅供参考
无其他回答

请教linux下用户态进程调度问题
jmp retint_check 这其实是用户态进程在用户态被中断打断后,从中断返回的流程,结合retint_careful+0x14\/0x32,进行反汇编,可以确认阻塞的点其实就在 SCHEDULE_USER 这其实就是调用schedule()进行调度,也就是说当进程走到中断返回的流程中时,发现需要调度(设置了TIF_NEED_RESCHED),于是在这里发...

linux进程的查看和调度
在抢占式调度中,内核会在特定时刻,如时间片用尽或高优先级进程请求时,强制切换当前进程。set_tsk_need_resched()标志的设置标志着抢占的触发点,而schedule()函数会在检查此标志时执行切换。用户态抢占通常在syscall返回或中断返回时发生,而在内核态,得益于CONFIG_PREEMPT编译选项,抢占更为灵活。在RHE...

从CPU架构开始,讲清楚Linux进程调度和管理
用户程序通过int指令进入内核,实现调用内核代码。中断导致系统从用户态转内核态,执行中断处理程序。进程调度与管理 单处理器系统下,多道程序设计实现CPU使用最大化。进程饥饿问题可通过定期提升优先级解决。协程是一种轻量级线程,适用于I\/O密集型场景,由用户控制切换。进程与线程的区别在于共享资源和调度...

为什么用户态程序在退出中断\/异常前,要运行调度程序?
因此,在用户态程序退出中断\/异常前,需要运行调度程序,让操作系统确定当前可运行的进程,并选择一个合适的进程切换到 CPU 上执行。这样可以避免上述问题的发生,同时也能够更好地管理和利用系统资源,提高系统的性能和稳定性。

进程调度
2. SJF: Shortest Job First SJF也是非抢占式调度,每次都选择最短的任务来执行。3. Shortest Remaining Time Next 是SJF的抢占式版本,只要有新任务到达就重新调度选择剩余时间最短的任务执行。SJF和Shortest Remaining Time Next的问题在于一般情况下很难判断进程的剩余执行时间是多少。除非这是经...

Linux进程调度的概述
直接调用调度程序。在每次反复循环中,驱动程序都检查need_resched的值,如果必要,则调用调度程序schedule()主动放弃CPU。4、进程从中断、异常及系统调用返回到用户态时 不管是从中断、异常还是系统调用返回,最终都调用ret_from_sys_call(),由这个函数进行调度标志的检测,如果必要,则调用调度程序。

linux为什么进程会有不同的运行模式?用户进程如何访问系统资源?_百度...
系统调用是用户态进程与内核态的接口,通过系统调用,用户态进程可以向内核请求执行特权操作或访问系统资源。用户进程通过向相应的系统调用接口传递参数,发起系统调用请求。内核收到请求后,在相应的内核函数中执行相应的操作,并返回结果给用户进程。总结来说,进程之所以有不同的运行模式,是为了保证操作系统...

Linux 内核的进程是如何管理?
程管理最核心的工作,由 Linux 内核调度器来完成。Linux 内核调度器根据进程的优先级选择最值得运行的进程。一个进程的可能状态有如下几种:(1) 运行态——已经获得了资源,并且进程正在被 CPU 执行。进程既可运行在内核态,也可运行在用户态。(2) 就绪态——当系统资源已经可用,但由于前一个...

Linux中的进程管理与分析linux进程sl
Linux还提供了一些特殊工具来实现进程管理,部分工具运行于内核态,它们主要对控制和调度进程进行控制,这些工具可以帮助操作系统以更高效的方式来控制进程。在用户态下,Linux提供的内存管理工具允许用户分析系统的内存动态,而内核的调度器则允许查看调度状态,包括当前正在运行的进程,等待的时间,等等。此外,...

linux线程是如何进行切换的?
这问题涉及调度机制、中断、内核抢占、新进程调度与上下文切换。在不支持内核抢占的Linux内核中,即使0号线程需要调度,内核不会立即调度线程1或线程2。只有在用户态中断或系统调用后检查是否需要调度。反之,在支持内核抢占的Linux内核中,中断返回时会检查当前进程是否需要调度。若需要,调度器将选择下一个...

相似回答