进程上下文、中断上下文以及中断程序的特点

进程上下文VS中断上下文

内核空间和用户空间是现代操作系统的两种工作模式,内核模块运行在内核空间,而用户态应用程序运行在用户空间。它们代表不同的级别,而对系统资源具有不同的访问权限。内核模块运行在最高级别(内核态),这个级下所有的操作都受系统信任,而应用程序运行在较低级别(用户态)。在这个级别,处理器控制着对硬件的直接访问以及对内存的非授权访问。内核态和用户态有自己的内存映射,即自己的地址空间。

www.2cto.com

处理器总处于以下状态中的一种:

1、内核态,运行于进程上下文,内核代表进程运行于内核空间;

2、内核态,运行于中断上下文,内核代表硬件运行于内核空间;

3、用户态,运行于用户空间。

用户空间的应用程序,通过系统调用,进入内核空间。由内核代表该进程运行于内核空间,这就涉及到上下文的切换,用户空间和内核空间具有不同的地址映射,通用或专用的寄存器组,而用户空间的进程要传递很多变量、参数给内核,内核也要保存用户进程的一些寄存器、变量等,以便系统调用结束后回到用户空间继续执行。

所谓的“进程上下文”,就是一个进程在执行的时候,CPU的所有寄存器中的值、进程的状态以及堆栈上的内容,当内核需要切换到另一个进程时,它需要保存当前进程的所有状态,即保存当前进程的进程上下文,以便再次执行该进程时,能够恢复切换时的状态,继续执行。

硬件通过触发信号,导致内核调用中断处理程序,进入内核空间。这个过程中,硬件的一些变量和参数也要传递给内核,内核通过这些参数进行中断处理。

www.2cto.com

所谓的“中断上下文”,其实也可以看作就是硬件传递过来的这些参数和内核需要保存的一些其他环境(主要是当前被中断的进程环境)。

当一个进程在执行时,CPU的所有寄存器中的值、进程的状态以及堆栈中的内容被称为该进程的上下文。当内核需要切换到另一个进程时,它需要保存当前进程的所有状态,即保存当前进程的上下文,以便在再次执行该进程时,能够必得到切换时的状态执行下去。在LINUX中,当前进程上下文均保存在进程的任务数据结构中。在发生中断时,内核就在被中断进程的上下文中,在内核态下执行中断服务例程。但同时会保留所有需要用到的资源,以便中继服务结束时能恢复被中断进程的执行。

Linux内核工作在进程上下文或者中断上下文。提供系统调用服务的内核代码代表发起系统调用的应用程序运行在进程上下文;另一方面,中断处理程序,异步运行在中断上下文。中断上下文和特定进程无关。

上下文context:上下文简单说来就是一个环境,相对于进程而言,就是进程执行时的环境。具体来说就是各个变量和数据,包括所有的寄存器变量、进程打开的文件、内存信息等。

一个进程的上下文可以分为三个部分:用户级上下文、寄存器上下文以及系统级上下文。

用户级上下文: 正文、数据、用户堆栈以及共享存储区;

寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP);

系统级上下文: 进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。

当发生进程调度时,进行进程切换就是上下文切换(context switch).操作系统必须对上面提到的全部信息进行切换,新调度的进程才能运行。而系统调用进行的是模式切换(mode switch)。模式切换与进程切换比较起来,容易很多,而且节省时间,因为模式切换最主要的任务只是切换进程寄存器上下文的切换。

进程上下文主要是异常处理程序和内核线程。内核之所以进入进程上下文是因为进程自身的一些工作需要在内核中做。例如,系统调用是为当前进程服务的,异常通常是处理进程导致的错误状态等。所以在进程上下文中引用current是有意义的。

内核进入中断上下文是因为中断信号而导致的中断处理或软中断。而中断信号的发生是随机的,中断处理程序及软中断并不能事先预测发生中断时当前运行的是哪个进程,所以在中断上下文中引用current是可以的,但没有意义。事实上,对于A进程希望等待的中断信号,可能在B进程执行期间发生。例如,A进程启动写磁盘操作,A进程睡眠后B进程在运行,当磁盘写完后磁盘中断信号打断的是B进程,在中断处理时会唤醒A进程。

内核可以处于两种上下文:进程上下文和中断上下文。在系统调用之后,用户应用程序进入内核空间,此后内核空间针对用户空间相应进程的代表就运行于进程上下文。异步发生的中断会引发中断处理程序被调用,中断处理程序就运行于中断上下文。中断上下文和进程上下文不可能同时发生。

  运行于进程上下文的内核代码是可抢占的,但中断上下文则会一直运行至结束,不会被抢占。因此,内核会限制中断上下文的工作,不允许其执行如下操作:

  (1) 进入睡眠状态或主动放弃CPU;

由于中断上下文不属于任何进程,它与current没有任何关系(尽管此时current指向被中断的进程),所以中断上下文一旦睡眠或者放弃CPU,将无法被唤醒。所以也叫原子上下文(atomic context)。

  (2) 占用互斥体;

为了保护中断句柄临界区资源,不能使用mutexes。如果获得不到信号量,代码就会睡眠,会产生和上面相同的情况,如果必须使用锁,则使用spinlock。

  (3) 执行耗时的任务;

中断处理应该尽可能快,因为内核要响应大量服务和请求,中断上下文占用CPU时间太长会严重影响系统功能。在中断处理例程中执行耗时任务时,应该交由中断处理例程底半部来处理。

  (4) 访问用户空间虚拟内存。

因为中断上下文是和特定进程无关的,它是内核代表硬件运行在内核空间,所以在中断上下文无法访问用户空间的虚拟地址

  (5) 中断处理例程不应该设置成reentrant(可被并行或递归调用的例程)。

因为中断发生时,preempt和irq都被disable,直到中断返回。所以中断上下文和进程上下文不一样,中断处理例程的不同实例,是不允许在SMP上并发运行的。

  (6)中断处理例程可以被更高级别的IRQ中断。

如果想禁止这种中断,可以将中断处理例程定义成快速处理例程,相当于告诉CPU,该例程运行时,禁止本地CPU上所有中断请求。这直接导致的结果是,由于其他中断被延迟响应,系统性能下降。

进程上下文、中断上下文以及中断程序的特点,布布扣,bubuko.com

时间: 07-25

进程上下文、中断上下文以及中断程序的特点的相关文章

用户空间与内核空间,进程上下文与中断上下文[总结]

用户空间与内核空间,进程上下文与中断上下文[总结] 最近有研究到zabbix监控,就得清楚cpu各个指标的含义, 1,简单回顾下cpu及计算机组成: 计算机五大部件: 运算器 控制器 存储器 输入/输出设备. 2,cpu 进程的内核态和用户态 我们知道现在操作系统都是采用虚拟存储器,那么对32位操作系统而言,它的寻址空间(虚拟存储空间)为4G(2的32次方).操心系统的核心是内核,独立于普通的应用程序,可以访问受保护的内存空间,也有访问底层硬件设备的所有权限.为 了保证用户进程不能直接操作内核,

【转】进程上下文和中断上下文、原子上下文的区别

内核空间和用户空间是现代操作系统的两种工作模式,内核模块运行在内核空间,而 用户态应用程序运行在用户空间.它们代表不同的级别,而对系统资源具有不同的访问权限.内核模块运行在最高级别(内核态),这个级下所有的操作都受系统信 任,而应用程序运行在较低级别(用户态).在这个级别,处理器控制着对硬件的直接访问以及对内存的非授权访问.内核态和用户态有自己的内存映射,即自己的 地址空间. 系统的两种不同于行状态,才有了上下文的概念.用户空间的应用程序,如果想请求系统服务,比如操作某个物理设备,映射设备的地址

Linux内核中进程上下文和中断上下文的理解

参考: http://www.embedu.org/Column/Column240.htm http://www.cnblogs.com/Anker/p/3269106.html 用户空间与内核空间 有了用户空间和内核空间,整个linux内部结构可以分为三部分,从最底层到最上层依次是:硬件-->内核空间-->用户空间.如下图所示: 需要注意的细节问题: (1) 内核空间中存放的是内核代码和数据,而进程的用户空间中存放的是用户程序的代码和数据.不管是内核空间还是用户空间,它们都处于虚拟空间中.

进程上下文与中断上下文

最近学习驱动程序中总是发现在某些资料或书籍中提到进程上下文和中断上下文,但是又都没有讲解什么是上下文:因此笔者查阅资料补充了一下所谓的Linux上下文知识.(注:以下知识度娘而来) 上下文(context): 指文章或说话中与某一词语或文句相连的上文和下文:这个词的含义联系上下文不难理解.都不知道谁造出一个这么晦涩难懂的词的,翻译成语境和环境多好理解. (注:以上是度娘对古代文人骚客创作该词的百科) LINUX完全注释中的一段话:当一个进程在执行时,CPU的所有寄存器中的值.进程的状态以及堆栈中

进程上下文、中断上下文及原子上下文

谈论进程上下文 .中断上下文 . 原子上下文之前,有必要讨论下两个概念: a -- 上下文 上下文是从英文context翻译过来,指的是一种环境.相对于进程而言,就是进程执行时的环境: 具体来说就是各个变量和数据,包括所有的寄存器变量.进程打开的文件.内存信息等. b -- 原子  原子(atom)本意是"不能被进一步分割的最小粒子",而原子操作(atomic operation)意为"不可被中断的一个或一系列操作" : 一.为什么会有上下文这种概念 内核空间和用户

Linux中断上下文

一.前言 每一个Linux驱动工程师都知道这样一个准则:在中断上下文中不能睡眠.但是为什么interrupt context中不能调用导致睡眠的kernel API呢?如果驱动这么做会导致什么样的后果呢?这就是本文探讨的主题.为了理解这个主题,我们设计了一些非常简单的驱动程序和用户空间的程序,实际做实验观察实验效果,最后给出了结果和分析. BTW,本文的实验在X86 64bit + 标准4.4内核上完成. 二.测试程序 1.cst驱动模块 我们首先准备一个能够在中断上下文中睡眠的驱动程序,在这里

关于中断上下文的理解

关于中断的问题之前一直都很模糊,尤其是对于中断上下文的概念理解上: 最近在以此项目中有幸接触到这一块,深入的看了一下,感觉理解深刻多了一些: 中断上下文在中断中是一个比较重要的概念,很有必要理解一下: 中断上半部:对于实时性要求比较高的部分,比如单纯做出中断事件类型的判断: 中断下半部:对于实时性要求比较低的一些操作,这一部分做的比较具体的事件.属于中断事件具体的处理部分: 当一个中断发生时,会先执行中断上半部,然后依据中断上半部的返回结果确定执行中断下半部具体的一些操作:

驱动:中断【2】中断处理程序、中断上下文中处理延时及一些函数的调用规则(调IIC中断驱动有感)

中断处理程序.中断上下文中处理延时及一些函数的调用规则(调IIC中断驱动有感)http://blog.csdn.net/samantha_sun/article/details/6790492 1,中断处理程序中不能使用有睡眠功能的函数,如ioremap,kmalloc,msleep等,理由是中断程序并不是进程,没有进程的概念,因此就没有休眠的概念: 2,中断处理程序中的延时可以用忙等待函数来代替,如ndelay,udelay,mdelay等,这些函数在实现上本质是根据CPU频率进行一定 次数的

Linux中断 - 驱动申请中断API

一.前言 本文主要的议题是作为一个普通的驱动工程师,在撰写自己负责的驱动的时候,如何向Linux Kernel中的中断子系统注册中断处理函数?为了理解注册中断的接口,必须了解一些中断线程化(threaded interrupt handler)的基础知识,这些在第二章描述.第三章主要描述了驱动申请 interrupt line接口API request_threaded_irq的规格.第四章是进入request_threaded_irq的实现细节,分析整个代码的执行过程. 二.和中断相关的lin