linux为什么不是实时操作系统

chengwei_peng 2024-07-07 16:07:03 阅读 99

Linux为什么不是实时操作系统?

从我们接触Linux系统开始,一直听到的都是它是非实时操作系统,怎么理解这个非实时呢?

我的理解,非实时,就是中断响应不及时,任务调度不及时。那么,真的是这样吗?下面先了解一下,Linux中断响应,是怎样的一个处理流程。

Linux是如何响应中断

ARM中断流程

ARM处理器的中断处理过程,可以分为以下几个步骤:

中断请求:外部设备或软件可以向ARM处理器发送中断请求信号,以通知处理器有需要处理的事件发生。中断请求可以是硬件中断(如外部设备的输入触发中断)或软件中断(通过软件指令触发中断)。中断检测:ARM处理器会周期性地检测中断请求是否发生。这个过程通常在每个指令周期的某个时刻进行,被称为中断检测阶段。如果检测到中断请求,处理器将进入中断处理流程。中断响应:当ARM处理器检测到中断请求时,它会保存当前的执行状态,并跳转到中断服务例程(ISR,Interrupt Service Routine)的入口地址。中断处理:进入中断服务例程后,ARM处理器将执行特定的中断处理代码,以完成对中断事件的处理。中断服务例程通常包括保存现场、处理中断事件、恢复现场等步骤。中断返回:在中断处理完成后,ARM处理器会从中断服务例程返回到原来的执行状态。处理器会恢复之前保存的现场,并继续执行被中断的指令。

我们在上面的第三步,存在一个保存现场的过程,它主要进行以下逻辑:

ARM异常处理:处理器对特定的异常事件进行的处理流程(CPU指导硬件自动完成:四大步三小步)。

一、保存现场(四大步):

保存CPSR到SPSR_mode

适当设置 CPSR 对应功能位(三小步):

a. 切换处理器进入ARM状态:T[5]

b. 根据需要,禁止中断位:F[6] / I[7]

c. 根据异常切换到对应的异常模式:M[4:0]

保存返回地址:把当前 PC 保存到 lr_mode

设置PC = 存放跳转到对应的异常向量表的固定首地址。

Linux的中断入口

我们关注中断响应和中断处理的过程,以ARM A55为例,Linux内核中,中断向量表在 arch/arm64/kernel/entry.S 中有定义:

<code>/*

* Exception vectors.

*/

.pushsection ".entry.text", "ax"

.align 11

SYM_CODE_START(vectors)

kernel_ventry 1, t, 64, sync // Synchronous EL1t

kernel_ventry 1, t, 64, irq // IRQ EL1t

kernel_ventry 1, t, 64, fiq // FIQ EL1h

kernel_ventry 1, t, 64, error // Error EL1t

kernel_ventry 1, h, 64, sync // Synchronous EL1h

kernel_ventry 1, h, 64, irq // IRQ EL1h

kernel_ventry 1, h, 64, fiq // FIQ EL1h

kernel_ventry 1, h, 64, error // Error EL1h

kernel_ventry 0, t, 64, sync // Synchronous 64-bit EL0

kernel_ventry 0, t, 64, irq // IRQ 64-bit EL0

kernel_ventry 0, t, 64, fiq // FIQ 64-bit EL0

kernel_ventry 0, t, 64, error // Error 64-bit EL0

kernel_ventry 0, t, 32, sync // Synchronous 32-bit EL0

kernel_ventry 0, t, 32, irq // IRQ 32-bit EL0

kernel_ventry 0, t, 32, fiq // FIQ 32-bit EL0

kernel_ventry 0, t, 32, error // Error 32-bit EL0

SYM_CODE_END(vectors)

而这个向量表,又是在什么时候设置到CPU的呢?

在 arch/arm64/kernel/head.S 中,有以下汇编代码:

/*

* The following fragment of code is executed with the MMU enabled.

*

* x0 = __PHYS_OFFSET

*/

SYM_FUNC_START_LOCAL(__primary_switched)

adr_l x4, init_task

init_cpu_task x4, x5, x6

adr_l x8, vectors // load VBAR_EL1 with virtual

msr vbar_el1, x8 // vector table address

isb

...

SYM_FUNC_END(__primary_switched)

从上面可以看到,将 vectors 的地址写入 vbar_el1 寄存器。

Exception level的Vector Base Address Register (VBAR)寄存器,该寄存器保存了各个exception level的异常向量表的基地址。该寄存器有三个,分别是VBAR_EL1,VBAR_EL2,VBAR_EL3。

为什么 vectors 会有 4x4 个向量呢?

exceptions

在ARM.v8体系结构中,中断只是异常的一种类型,异常有4种类型。

同步异常:这种类型的异常总是由当前执行的指令引起。例如。可以使用str 指令将一些数据存储在不存在的内存位置。在这种情况下,将生成同步异常。同步异常也可以用于生成 软件中断。软件中断是由svc指令有意产生的同步异常。IRQ(中断请求):这些是正常的中断。它们始终是异步的,这意味着它们与当前执行的指令无关。与同步异常相反,它们始终不是由处理器本身生成的,而是由外部硬件生成的。FIQ(快速中断请求):这种类型的异常称为快速中断,仅出于优先处理异常的目的而存在。可以将某些中断配置为“正常”,将其他中断配置为“快速”。快速中断将首先发出信号,并将由单独的异常处理程序处理。Linux不使用快速中断。SError(系统错误):像IRQFIQ一样,SError异常是异步的,由外部硬件生成。与 IRQFIQ 不同,SError 始终表示某种错误情况。

异常向量

每种异常类型都需要有自己的处理程序。另外,同一种异常类型下不同的状态也需要定义单独的处理程序。典型的有4种状态,以EL1 为例,这些状态可以定义如下:

EL1t 与EL0共享堆栈指针时,EL1发生异常。当 SPSel 寄存器的值为 0 时,就会发生这种情况。EL1h 为EL1分配了专用堆栈指针时,EL1发生了异常。这意味着 SPSel 拥有值 1,这是我们当前正在使用的模式。EL0_64 以64位模式执行的EL0产生异常。EL0_32 以32位模式执行的EL0产生异常。

总共,我们需要定义16个异常处理程序(4个异常级别乘以4个执行状态)。

当外部gpio中断来了的时候,我们进入的是IRQ EL1h,当访问内存产生的缺页异常,进入的是Synchronous EL1h

当外部gpio中断来了,查询向量表,满足kernel_ventry 1, h, 64, irq,kernel_ventry 是在 arch/arm64/kernel/entry.S 实现的一个函数,上面展开后,就是调用 el1h_64_irq 这个函数。el1h_64_irq 还是一个汇编宏展开,在 arch/arm64/kernel/entry.S 有这样的代码:

.macro entry_handler el:req, ht:req, regsize:req, label:req

SYM_CODE_START_LOCAL(el\el\ht\()_\regsize\()_\label)

kernel_entry \el, \regsize

mov x0, sp

bl el\el\ht\()_\regsize\()_\label\()_handler

.if \el == 0

b ret_to_user

.else

b ret_to_kernel

.endif

SYM_CODE_END(el\el\ht\()_\regsize\()_\label)

.endm

/*

* Early exception handlers

*/

...

entry_handler 1, h, 64, irq

...

可以看到,通过SYM_CODE_START_LOCAL定义函数,在 kernel_entry 中做寄存器数据入栈等现场保护,然后bl跳转到 el1h_64_irq_handler,而el1h_64_irq_handler则是C语言实现的代码了。

el1h_64_irq_handler

el1h_64_irq_handler实际上是在 el1_interrupt 的基础上,再调用handle_arch_irq函数,在看handle_arch_irq函数之前,我们先看看el1_interrupt 都做了哪些操作。

el1_interrupt的逻辑:

关外部中断;通过 do_interrupt_handler 调用到中断处理函数,do_interrupt_handler 会判断当前是否在任务的栈上,如果在栈上还需要保存现场,否则直接调用handle_arch_irq;通过 arm64_preempt_schedule_irq 函数进行抢占式调度任务;开外部中断;

上面的handle_arch_irq就是一个函数指针,以gicv3为例,该函数指针指向的是gic_handle_irq()。

gic_handle_irq

do_read_iar 获取中断号;检查是否支持NMI(非屏蔽中断),并读取RPR(运行优先级寄存器)的值。如果RPR的值等于GICD_INT_RPR_PRI(GICD_INT_NMI_PRI)则调用gic_handle_nmi()函数来处理NMI;检查是否启用了GIC(通用中断控制器)的优先级屏蔽功能。如果启用了,则调用gic_pmr_mask_irqs()函数来屏蔽中断,并调用gic_arch_enable_irqs()函数来启用中断;gic_complete_ack将中断ID写入ICC_EOIR1_EL1寄存器来停止这个中断,我理解应该是类似清除gic的中断pending位信息;接下来就是调用中断处理函数handle_domain_irq;

handle_domain_irq

irq_resolve_mapping 通过hwirq查找irq_desc;接着调用handle_irq_desc函数来处理中断描述符irq_desc,里面重点是调用 irq_desc->handle_irq 函数;这个irq_desc->handle_irq函数由irq_chip->irq_nmi_teardown设置,SGI/PPI/EPPI对应handle_percpu_devid_irq,其他对应handle_fasteoi_irq。最终handle_fasteoi_irq会调用action->handler来执行中断处理函数,这个action->handler就是我们通过request_irq或者request_threaded_irq设置的中断处理函数;

针对这个,建议查看参考文章i.MX8MP平台开发分享(gicv3篇)-- gic_handle_irq如何跳转到自定义的中断线程处理函数,里面针对硬件寄存器的介绍也比较详细。

中断的实时性讨论

在没有进行上面的代码跟进的时候,我之前一直以为,linux的中断非实时,是因为Linux系统在获知硬件中断之后,仅仅是立马清除了中断的pending信息,等到合适的时间再去进行中断函数的处理,从而导致中断非实时。但是从上面的代码分析下来发现,我之前的理解都是错误的,可以说,Linux系统在不关中断的情况下,只要产生了中断,都是会立马处理中断的。

那么为什么说Linux中断是非实时的呢?

因为Linux太多关闭中断的地方了,如上面,在处理中断的时候,关闭了中断(Linux不允许中断嵌套);在系统进入临界区的时候会调用spin_lock_irqsave等,关闭中断的地方多了,影响外部中断的时候,就需要等待使能中断后才可以响应,从而不满足非实时。

而像RT Linux,为了提高中断实时性,它主要进行了以下几点的修改:

临界区可抢占,将spinlock修改为可抢占类型,避免大量的关闭中断;中断处理线程化,减少关闭中断的时间;

从RT Linux的修改,都是为了减少关闭中断的时间来提高实时性。从这个方面去理解Linux的中断非实时,就更容易理解了吧。

Linux任务什么时候调度

首先,Linux的进程是抢占式的,内核配置CONFIG_PREEMPT默认是开启的,当一个高优先级的进入可运行状态,内核将会检查它的动态优先级是否大于当前正在运行进程的优先级。如果是,当前运行的进程将会被中断,并调用调度程序选择另外一个程序运行。

在中断处理完之后,任务也会有机会发生调度,具体的代码段如下:

// arch/arm64/kernel/entry-common.c

static void noinstr el1_interrupt(struct pt_regs *regs,

void (*handler)(struct pt_regs *))

{

write_sysreg(DAIF_PROCCTX_NOIRQ, daif);

enter_el1_irq_or_nmi(regs);

do_interrupt_handler(regs, handler);

/*

* Note: thread_info::preempt_count includes both thread_info::count

* and thread_info::need_resched, and is not equivalent to

* preempt_count().

*/

if (IS_ENABLED(CONFIG_PREEMPTION) &&

READ_ONCE(current_thread_info()->preempt_count) == 0)

arm64_preempt_schedule_irq(); //可抢占,则发生调度

exit_el1_irq_or_nmi(regs);

}

时常我们会说,从内核返回用户空间的时候,也会发生任务调度,这个从用户空间进入内核的时候,也是通过异常进入的(或者说是软中断,PPI?),实际上这个和中断应该是没有本质的区别吧?所以他们归类为一种,都是异常处理后的任务调度。

最后,还有一种是时间片用完之后的任务调度,这个就很好理解了,给你的时间用完了,就要切换出去,不能让你自己一个人玩。

参考:

ARM中断处理过程及编程实例

ARM-中断状态,中断响应流程(四大步三小步)

ARM64 kernel exception vectors

i.MX8MP平台开发分享(gicv3篇)-- gic_handle_irq如何跳转到自定义的中断线程处理函数

【进程】preempt_count解析

[工业互联-15]:Linux操作与实时Linux操作系统RT Linux( PREEMPT-RT、Xenomai)

【进程调度】执行调度的时机



声明

本文内容仅代表作者观点,或转载于其他网站,本站不以此文作为商业用途
如有涉及侵权,请联系本站进行删除
转载本站原创文章,请注明来源及作者。