如果系统中断较少的话#xff0c;其管理就不用设计这样一个中断子系统这…目录

5-中断子系统

如果系统中断较少的话其管理就不用设计这样一个中断子系统这么麻烦了。

但是现代CPU功能越来越强大越来越复杂自然支持的中断数量也不断增加。

中断由专门的中断控制器在硬件层面管理另外还存在中断嵌套的问题这样中断号就可能冲突重叠或重复

为了总揽中断处理内核设计了多个数据结构完善对中断的管理。

这些数据结构包括

irq_desc中断描述结构包含中断的数据中断的处理函数指针列表以及相关的其他信息比如父中断、任务相关信息

一个实际的中断会对应到一个irq_desc,结构系统创建时候会初始化一个irq_desc全局列表数组每当驱动调用request_irq请求中断时

就在irq的全局列表中找到一个对应的节点如果申请的中断号存在的话则复用已有的如果没有的话就新分配一个给当前中断号

当前申请中断的回调函数就会挂载到该描述符的action列表上当中断产生后会根据硬件中断号找到软件中断号进而找到该描述符遍历执行挂接其上的回调函数

irq_data中断数据结构体该数据结构包含了当前软件中断号及其对应的硬件中断号也包含了irq_chip和irq_domain结构指针。

irq_chip结构表示了一个中断控制器这个结构里预定义了多个函数指针主要用来进行中断控制器的一些操作比如屏蔽、取消中断屏蔽等

irq_domain结构表示了一个中断控制器管理的中断。

通过该接口中断控制器要建立该中断控制器管理的中断的映射关系。

内核启动时完成中断系统的构建也就是描述符表的初始化中断控制器驱动的加载完成中断子系统的初始化。

中断是系统正常运行的基础子系统许多模块的正常运行依赖该子系统所以需要较早初始化。

即使这样中断也有其依赖的部分比如内存分配所以内存的初始化要放在其前面另外CPU本身的初始化也是最初要做的。

上述工作会在CPU中断关闭的情况下进行。

因为这个阶段即使产生中断也是没有意义的没有谁去处理它。

笼统的来讲所有中断子系统用到的东西都必须先于其构建比如像radix树之类的。

这之后内核调用early_irq_init();和init_IRQ();构建中断子系统。

第一个接口完成中断描述符相关内容的构建第二个接口一般是平台相关的调用。

比如接口中进一步调用machine_desc-init_irq();完成具体平台的中断初始化。

对于海思平台在其march-hisi中的core.c中定义了这里用到的machine进一步的会调用hi3536_gic_init_irq完成平台中断的初始化。

平台部分会做一些额外或者也可能不做最终会调用通用中断初始化接口gic_init_bases

网上介绍的gic_of_init初始化接口也会调用到上述接口上殊途同归吧。

在这个接口里会完成CPU内置中断0-31号的配置完成GIC通用中断控制器的创建和映射关系建立以及用户定义中断的配置

另外这里会使用CPU的中断相关寄存器地址。

hisi平台machine在调用通用中断初始化接口时会传递海思平台的寄存器地址完成海思平台中断子系统的初始化

驱动申请中断时主要是根据中断类型、中断号等信息将当前设备的中断处理程序挂接到中断描述符结构上全局的中断描述符。

当中断产生后会一级一级向上传导到中断控制器最终到CPU。

CPU响应中断后会获取到当前最终一级的中断号。

这个中断号是硬件的通过该中断号一级一级向下传导。

先通过irq_chip这个代表中断控制器的结构关闭或者屏蔽当前中断控制器的中断

具体是那个最下一级设备最终产生的中断这就要交给中断处理函数了。

在驱动申请中断时预先定义了中断处理函数。

驱动需要判断当中断处理函数被调用时是否是当前设备产生了中断这可以通过读取设备的中断寄存器来完成判决。

其实中断的申请分共享和非共享对于非共享中断此时应该就是也必须是设备的中断触发其中断处理函数否则说明系统中断部分的映射有问题。

锁、延迟与原子上下文

全局共享队列不能延迟调度,因为是默认内核专门的线程,该线程应该是不能延迟操作?

因为队列中的work什么时候执行要看之前的work什么时候执行完成

msec

(show_stack0x10/0x14)4[c0016de4]

from

(__schedule_bug0x50/0x64)4[c0546340]

from

(__schedule0x4f0/0x5d8)4[c054c454]

from

(schedule_timeout0x130/0x1ac)4[c054a9e0]

from

(call_timer_fn.isra.300x24/0x88)4[c0032374]

(call_timer_fn.isra.300x24/0x88)

from

(run_timer_softirq0x194/0x210)4[c003256c]

from

(__do_softirq0x124/0x204)4[c002bb54]

from

(handle_IRQ0x44/0x90)4[c0013ea0]

from

(gic_handle_irq0x34/0x8c)4[c0008514]

from

(arch_cpu_idle0x2c/0x30)4[c00142a8]

from

(cpu_startup_entry0xfc/0x140)4[c005b360]

from

(show_stack0x10/0x14)4[c0016de4]

from

(dequeue_task_idle0x34/0x40)4[c0050ab4]

from

(__schedule0x2dc/0x5d8)4[c054c240]

from

(schedule_timeout0x130/0x1ac)4[c054a9e0]

from

(call_timer_fn.isra.300x24/0x88)4[c0032374]

(call_timer_fn.isra.300x24/0x88)

from

(run_timer_softirq0x194/0x210)4[c003256c]

from

(__do_softirq0x124/0x204)4[c002bb54]

from

(handle_IRQ0x44/0x90)4[c0013ea0]

from

(gic_handle_irq0x34/0x8c)4[c0008514]

from

0xcf867fe0)关于锁需要关注一些跟硬件相关的特性或者手段更为贴切。

原子操作汇编层面使用CPU内部特性保证

https://zhuanlan.zhihu.com/p/88883239

https://blog.csdn.net/cfy_phonex/article/details/12090943

RCU

如果CPU层面没有相关手段软件层面可能需要特别处理中断比如关闭中断保证当前代码执行不被打断。

内存管理子系统

内存管理子系统也是系统中非常基础的模块许多其他模块都依赖该模块所以内存管理子系统在系统中初始化的位置很靠前

现代操作系统都采用了虚拟内存系统以此提供进程间的共享、隔离和独立的不依赖物理内存大小的地址空间

Linux对物理内存进行了分区管理提供了DMA区域、正常区域和高端区域

DMA区域针对某些物理设备可访问物理内存地址范围受限的情况一般是在低地址区

正常区域为分页划分后供系统使用的内存这部分内存的映射一般是固定映射通常为一个固定偏移。

内核地址空间3G到4G之间的低地址部分会映射到物理内存的对应低地址区域。

高端内存为正常区域之外的物理内存这部分内存需要时单独映射到内核地址空间该映射非固定映射需要时通过系统接口建立映射用完释放。

上述区域的划分在不同平台可能有不同的实现有的平台可能不存在高端内存也可能不存在DMA区域。

是获取和释放页面。

这是最底层的接口。

通过这类接口可直接获取物理内存页并使用。

一般不建议通过该方法获取内存。

是通过kmalloc获取内存buffer。

该接口基于1中的接口但是中间增加了slab管理算法。

通过slab算法可以有效的管理物理内存。

相比第一种的页为单位的内存通过该接口获取内存更灵活。

当然slab也是先通过1接口获取空闲页再进行管理后提供给kmalloc调用者。

是通过vmalloc获取内存buffer。

跟2比较该接口获取的内存在虚拟空间中连续物理地址不连续。

可能是多个零散的物理页面通过映射表产生虚拟空间的连续内存。

显然该接口获取内存对性能有一定损耗所以一般也不用该接口除非需要获取较大的物理内存。

模块加载时通常通过该接口获取内存。

除了操作系统自身的内存管理需要Linux操作系统还需要提供进程的内存管理。

进程的内存管理通过挂接到task结构体上的mm结构体进行管理。

mm结构体进一步挂接vma结构体链表具体对应用户进程的地址空间。

用户进程的/proc/xxx/mmap文件就是vma的对应其中包括共享库、堆、栈、进程自身动态库、代码段、数据段等区块。

一般栈向下增长堆向上增长。

对于内核进程来讲是不存在上述mm结构体的内核进程不需要共享库以及其他部分。

内核进程之间是全局共享的此处用内核线程更好理解。

内核一个大进程有很多线程。

内核堆栈代码段数据段等是在内核加载后逐步建立的堆栈占用物理内存的固定区域一般栈在最高地址处。

其他内存通过调用分配函数完成。

内存的使用没有差异只是内核的内存映射在内核地址空间。

可以想象内核是一个大进程所有内核线程和用户进程都共享内核地址空间。

虚拟内存通过MMU访问但是也要看到建立物理映射需要多次访问内存对性能影响不小特别是进程切换等操作映射很容易失效。

系统提供TLB用于页表映射的CACHE对性能提升有很大影响。

一般页面的大小在4KB及以上使用内存过程中根据空间相关性同一页面的高频访问概率还是很大的CACHE带来的效率提升会比较高。

随着现代64位系统的流行和应用的不断复杂化、膨胀化应用对内存的消耗也在不断地增加。

使用4KB的页面可能导致出现频繁的页分配释放和CACHE

line

占用对性能的提升有不少帮助。

但同时也要看到大页也有其不利的一面比如利用率可能造成浪费、分配成功率等。

需要平衡考虑。

框架一模板化

(chrdev_open0xc4/0x1ac)4[c00c2f38]

from

(do_dentry_open.isra.160x164/0x258)4[c00bd2a0]

(do_dentry_open.isra.160x164/0x258)

from

(finish_open0x20/0x38)4[c00bd3b4]

from

(do_last.isra.540x3bc/0xc24)4[c00cb3c0]

from

(path_openat.isra.550xac/0x470)4[c00cbcd4]

(path_openat.isra.550xac/0x470)

from

(do_filp_open0x2c/0x80)4[c00ccce4]

from

(do_sys_open0xe8/0x170)4[c00be320]

from