📚 课程目录第4章中断上下文与实时性

4. 中断上下文与实时性：进程上下文与中断上下文、实时内核(PREEMPT_RT)对中断的影响

在嵌入式Linux系统中，GPIO中断的处理路径横跨两种截然不同的执行环境：中断上下文与进程上下文。理解这两种上下文的区别，以及实时内核（PREEMPT_RT）如何重塑中断处理模型，是优化GPIO中断实时性与内存访问延迟的基石。

4.1 进程上下文与中断上下文的核心差异

中断上下文（也称为原子上下文）与进程上下文是Linux内核中两种最基本的执行环境。它们的主要区别在于可阻塞性、调度能力以及可访问的资源。

特性	进程上下文	中断上下文
可睡眠/阻塞	是（可以调用 schedule()）	否（禁止睡眠）
可被抢占	是（取决于内核配置）	否（传统内核中不可被抢占）
持有锁类型	互斥锁（mutex）、信号量	自旋锁（spinlock）、原子操作
访问用户空间	是（copy_from/to_user）	否（可能导致缺页异常而睡眠）
执行时间要求	相对宽松	极短（微秒级，否则丢中断）
GPIO中断典型操作	读取完整数据、唤醒用户态线程	清除中断标志、记录时间戳、调度 tasklet/workqueue

    关键原则：中断上下文是系统的“紧急通道”，必须快速进出。任何可能导致睡眠的操作（如互斥锁、内存分配、用户空间访问）在中断上下文中都是致命的，会导致内核崩溃（kernel panic）或死锁。

4.2 中断上下文处理流程与瓶颈

一个典型的GPIO中断处理流程分为上半部（Top Half）和下半部（Bottom Half）。上半部在中断上下文中立即执行，下半部在稍后的安全时机（通常是进程上下文）执行。

性能陷阱：许多GPIO驱动开发者错误地将大量计算或内存操作放在上半部，导致中断延迟（Interrupt Latency）飙升。对于高速GPIO中断（如编码器信号），上半部执行时间过长会直接导致中断丢失。

4.3 实时内核（PREEMPT_RT）对中断模型的变革

标准Linux内核（CONFIG_PREEMPT_NONE或CONFIG_PREEMPT_VOLUNTARY）中，中断上下文具有最高优先级，不可被任何进程抢占。这虽然保证了中断的快速响应，但带来了一个严重问题：一个高频率的GPIO中断可能会无限期地延迟实时任务的执行。

PREEMPT_RT补丁集（已合入主线内核的实时配置选项）从根本上改变了这一模型，其核心思想是将中断线程化。

4.3.1 中断线程化（Interrupt Threading）

在PREEMPT_RT内核中，大部分中断处理程序的上半部不再在原子中断上下文中运行，而是作为一个实时内核线程（IRQ thread）来执行。这个线程拥有实时优先级，可以被调度器管理。

4.3.2 自旋锁与互斥锁的转换

在标准内核中，中断上下文只能使用自旋锁。PREEMPT_RT通过将自旋锁实现为实时互斥锁（rt_mutex），使得原本在中断上下文中不能睡眠的限制被打破。当中断线程持有“自旋锁”时，如果发生锁冲突，线程可以睡眠等待，而不会忙等（busy-wait）。

锁类型	标准内核行为	PREEMPT_RT 行为
spin_lock()	忙等（禁止抢占）	映射为 rt_mutex，可睡眠等待
raw_spin_lock()	忙等（禁止抢占）	仍为忙等（用于真正原子上下文）
local_irq_disable()	关闭本地CPU中断	可能触发实时优先级继承

GPIO驱动适配建议：在编写PREEMPT_RT兼容的GPIO中断驱动时，应优先使用 spin_lock() 而非 raw_spin_lock()。前者在RT内核中会自动获得可睡眠的特性，从而降低中断处理对系统实时性的影响。只有在真正需要禁止中断的极短临界区（如访问硬件寄存器）时，才使用 raw_spin_lock()。

4.4 实时性指标：中断延迟与调度抖动

评估GPIO中断实时性有两个关键指标：

中断延迟（Interrupt Latency）：从硬件中断信号产生到CPU开始执行中断处理程序第一条指令的时间。在PREEMPT_RT中，由于中断线程化，这个延迟可能略有增加，但确定性更好。
调度抖动（Jitter）：实时任务实际唤醒时间与预期唤醒时间的偏差。PREEMPT_RT通过允许高优先级任务抢占中断线程，大幅降低了调度抖动。

4.5 实践：在GPIO驱动中正确处理上下文

以下是一个针对PREEMPT_RT优化的GPIO中断驱动片段，展示了如何显式区分上下文并选择合适的机制：

/* GPIO中断上半部 - 在中断上下文或中断线程中执行 */
static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
{
    struct gpio_dev *dev = (struct gpio_dev *)dev_id;
    unsigned long flags;

    /* 1. 原子操作：清除中断标志，读取硬件状态 */
    raw_spin_lock(&dev->hw_lock);
    dev->hw_status = ioread32(dev->regs + GPIO_STATUS);
    iowrite32(dev->hw_status, dev->regs + GPIO_ACK);
    raw_spin_unlock(&dev->hw_lock);

    /* 2. 记录时间戳（ktime_get 在中断上下文安全） */
    dev->timestamp = ktime_get();

    /* 3. 调度工作队列处理复杂逻辑（仅在非线程化中断中需要） */
    if (!irq_disabled()) {
        /* 标准内核：必须调度下半部 */
        schedule_work(&dev->work);
    } else {
        /* PREEMPT_RT：中断线程中可以直接处理更多逻辑 */
        /* 注意：仍不能调用可能导致睡眠的函数（如mutex_lock） */
    }

    return IRQ_HANDLED;
}

/* 下半部 - 在进程上下文中执行 */
static void gpio_work_handler(struct work_struct *work)
{
    struct gpio_dev *dev = container_of(work, struct gpio_dev, work);

    /* 可以安全地使用互斥锁 */
    mutex_lock(&dev->read_lock);

    /* 可以访问用户空间（如果有缓冲区） */
    /* copy_to_user(dev->buffer, ...); */

    /* 可以唤醒等待队列中的用户态进程 */
    wake_up_interruptible(&dev->wait_queue);

    mutex_unlock(&dev->read_lock);
}

    PREEMPT_RT 下的最佳实践：
    优先使用中断线程：在设备树或平台数据中标记 IRQF_NO_THREAD 标志，除非绝对必要（如定时器中断），否则让中断线程化。
区分锁的使用：保护硬件寄存器的临界区使用 raw_spin_lock()；保护软件数据结构的临界区使用 spin_lock()（在RT下自动变为可睡眠）。
避免在中断线程中调用 schedule()：虽然中断线程可以睡眠，但显式调用调度器会引入不必要的延迟。
使用 ktime_get() 而非 do_gettimeofday()：前者在中断上下文和实时上下文中都是安全的，且精度更高。

4.6 总结：上下文选择决策树

在GPIO中断优化中，根据内核配置和实时性需求，选择正确的处理上下文至关重要：