[系统运维]Linux抢占是如何发生的？

参考博客:

抢占是如何发生的 - 云+社区 - 腾讯云抢占是如何发生的。相应的调度器核心层代码是sched_fork()，它再通过调度类的task_fork方法触发抢占：4进程修改nice值的时候如果进程修改nice值导致优先级高于CPU上的当前进程，也会触发抢占。执行抢占的时机触发抢占通过设置进程的TIF_NEED_RESCHED标志告诉调度器需要进行抢占操作了，但是真正执行抢占还要等内核代码发现这个标志才行，而内核代码只在设定的几个点上检查TIF_NEED_RESCHED标志，这也就是执行抢占的时机。https://cloud.tencent.com/developer/news/103525

Linux用户抢占和内核抢占详解(概念, 实现和触发时机)--Linux进程的管理与调度(二十）_OSKernelLAB(gatieme)-CSDN博客_内核抢占Linux用户抢占和内核抢占详解(概念, 实现和触发时机) 日期 内核版本 架构 作者 GitHub CSDN 2016-07-01 Linux-4.6 X86 & arm gatieme LinuxDeviceDrivers Linux进程管理与调度前面我们了解了linux进程调度器的设计思路和注意框架周期调度器scheduler_tick通过linhttps://blog.csdn.net/gatieme/article/details/51872618

Linux进程管理（四）进程调度之抢占式调度_JT同学的博客-CSDN博客_linux抢占式调度Linux进程管理（四）进程调度之抢占式调度文章目录Linux进程管理（四）进程调度之抢占式调度一、抢占式调度二、设置需要重新调度的标志的时机（TIF_NEED_RESCHED）三、进程抢占的时机3.1 用户态的抢占时机3.2 内核态的抢占时机四、总结上篇文章我们将了内核调度分为主动调度和抢占式调度，主动调度我们已经讲解过了，这篇文章我们来讲解一下抢占式调度一、抢占式调度我们说过，进程真正...https://blog.csdn.net/weixin_42462202/article/details/102954818

0. 问题背景

我们都知道自旋锁spinlock中有关/开抢占的操作，前面我有一篇文章也分析了为什么spinlock内部要关闭抢占，但是对于什么是抢占，抢占的机理是什么，一直都是模模糊糊的概念，所以需要在这里浅析一下

其实对于Linux内核的抢占机制，阅读参考博客就够了，本篇文章也是基于它的一个总结与概括

1. 非抢占与抢占

非抢占式内核有实时性上的缺点，高优先级的任务即使处于就绪状态，也不一定能够得到及时的调度，而什么时候调度高优先级的任务完全取决于当前在CPU上的任务什么时候主动让出CPU，这一点就对实时性非常不友好

?

抢占式内核对Linux的实时性支持就很友好，最高优先级的任务什么时候可以执行，可以得到CPU的使用权是可知的。使用抢占式内核使得任务级响应时间得以最优化

但是抢占式内核必须小心抢占任务和被抢占任务之间的竞态问题(Race Condition)

用<深入Linux设备驱动内核机制>中的话说，调度器的可抢占性也是并发的来源之一

?

2. 抢占式调度机制

用博客中总结的图来描述

?抢占式调度主要分为两步，第一步就是设置进程的TIF_NEED_RESCHED标志，此时进程还没有被抢占，仍然继续运行，在到达某些调度点的时候，抢占才会实际发生

./include/linux/sched.h

./include/linux/thread_info.h

?可以看到，TIF_NEED_RESCHED的设置就是将当前进程的flag成员某位置1，TIF表示Thread InFo，置位的时机在周期性调度处理器与唤醒进程的操作中

进程抢占的时机指的是什么时候检查TIF_NEED_RESCHED标志进而进行抢占调度，内核中抢占的时机有两处，第一处是从中断返回内核态的时候，第二处是抢占使能的时候

./arch/arm64/kernel/entry.S

?可以看到如果满足抢占的条件(抢占开启，TIF置位)，那么在中断返回内核态的抢占点，会调用__schedule()将被中断的进程换出处理器运行队列，再从处理器的运行队列中选择一个进程运行从而完成抢占，从另一个方面来说，虽然中断返回内核态是一个抢占点，但如果条件不满足，抢占不会成功

?

?

?

?

同理，在抢占开启的时候，也会检查一系列条件，如果条件满足，才会调用 __schedule()完成抢占

以上便是Linux内核抢占的大概机制，在这里需要明确以下几点：

• 抢占式内核可以提高系统的实时性，但是随之而来的缺点是它也是并发的来源之一
• 抢占分为两步走，第一步设置TIF_NEED_RESCHED标志位，此时抢占并未实际发生
• 抢占分为两步走，第二步在调度点检查是否满足抢占的条件进行抢占操作
• 进程真正的调度都是通过调用 schedule 函数发生的，所谓抢占抢占式调度，就是非进程自愿调用 schedule 来发生进程调度

?3.一个思考题

上面浅析了抢占式如何发生的，spin lock irq中既然关闭了CPU响应中断的能力，那么在拥有自旋锁的上下文中，即使当前进程的TIF_NEED_RESCHED标志被置位了，也不可能有中断来临触发抢占点，那么为什么spin lock irq中要显示地关闭抢占呢？

StackOverflow中举出了内核文档中的话：./Documentation/preemt-locking.txt

?一个比较靠谱的说法是，下列情形可能会出问题：

?

??

local_irq_save();

......

_cond_resched();

local_irq_restore();

假如在CONFIG_PREEMPT_VOLUNTARY=y的情况下，很有可能当前任务被别的任务设置了TIF_NEED_RESCHED标志位并且当前没有显示关闭抢占(preempt_count==0)，这时候便会调用preempt_schedule_common()->__schedule()将当前进程从运行队列中移除，而这个时候是获取到锁的，便有可能别的任务得不到锁而卡滞，甚至有死锁风险

?kernel - why spin_lock_irqsave needs to disable preemption on multiprocessor - Stack Overflowhttps://stackoverflow.com/questions/27210315/why-spin-lock-irqsave-needs-to-disable-preemption-on-multiprocessor/63939567

?