从我们接触Linux系统开始，一直听到的都是它是非实时操作系统，怎么理解这个非实时呢？
我的理解，非实时，就是中断响应不及时，任务调度不及时。那么，真的是这样吗？下面先了解一下，Linux中断响应，是怎样的一个处理流程。
ARM处理器的中断处理过程，可以分为以下几个步骤：
我们在上面的第三步，存在一个保存现场的过程，它主要进行以下逻辑：
ARM异常处理：处理器对特定的异常事件进行的处理流程（CPU指导硬件自动完成：四大步三小步）。
一、保存现场(四大步)：
保存CPSR到SPSR_mode
适当设置 CPSR 对应功能位（三小步）：
a. 切换处理器进入ARM状态：T[5]
b. 根据需要，禁止中断位：F[6] / I[7]
c. 根据异常切换到对应的异常模式：M[4:0]
保存返回地址：把当前 PC 保存到 lr_mode
设置PC = 存放跳转到对应的异常向量表的固定首地址。
我们关注中断响应和中断处理的过程，以ARM A55为例，Linux内核中，中断向量表在 arch/arm64/kernel/entry.S 中有定义：
/*
* 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指令有意产生的同步异常。快速中断，仅出于优先处理异常的目的而存在。可以将某些中断配置为“正常”，将其他中断配置为“快速”。快速中断将首先发出信号，并将由单独的异常处理程序处理。Linux不使用快速中断。IRQ和FIQ一样，SError异常是异步的，由外部硬件生成。与 IRQ 和 FIQ 不同，SError 始终表示某种错误情况。异常向量
每种异常类型都需要有自己的处理程序。另外，同一种异常类型下不同的状态也需要定义单独的处理程序。典型的有4种状态，以EL1 为例，这些状态可以定义如下：
EL1发生异常。当 SPSel 寄存器的值为 0 时，就会发生这种情况。SPSel 拥有值 1，这是我们当前正在使用的模式。总共，我们需要定义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实际上是在 el1_interrupt 的基础上，再调用handle_arch_irq函数，在看handle_arch_irq函数之前，我们先看看el1_interrupt 都做了哪些操作。
el1_interrupt的逻辑：
上面的handle_arch_irq就是一个函数指针，以gicv3为例，该函数指针指向的是gic_handle_irq()。
gic_handle_irq
handle_domain_irq
针对这个，建议查看参考文章i.MX8MP平台开发分享（gicv3篇）-- gic_handle_irq如何跳转到自定义的中断线程处理函数，里面针对硬件寄存器的介绍也比较详细。
在没有进行上面的代码跟进的时候，我之前一直以为，linux的中断非实时，是因为Linux系统在获知硬件中断之后，仅仅是立马清除了中断的pending信息，等到合适的时间再去进行中断函数的处理，从而导致中断非实时。但是从上面的代码分析下来发现，我之前的理解都是错误的，可以说，Linux系统在不关中断的情况下，只要产生了中断，都是会立马处理中断的。
那么为什么说Linux中断是非实时的呢？
因为Linux太多关闭中断的地方了，如上面，在处理中断的时候，关闭了中断（Linux不允许中断嵌套）；在系统进入临界区的时候会调用spin_lock_irqsave等，关闭中断的地方多了，影响外部中断的时候，就需要等待使能中断后才可以响应，从而不满足非实时。
而像RT Linux，为了提高中断实时性，它主要进行了以下几点的修改：
从RT 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？），实际上这个和中断应该是没有本质的区别吧？所以他们归类为一种，都是异常处理后的任务调度。
最后，还有一种是时间片用完之后的任务调度，这个就很好理解了，给你的时间用完了，就要切换出去，不能让你自己一个人玩。
ARM64 kernel exception vectors
i.MX8MP平台开发分享（gicv3篇）-- gic_handle_irq如何跳转到自定义的中断线程处理函数