一种操作系统内核切换方法和装置

技术领域

本发明涉及系统调用技术领域,尤其涉及一种操作系统内核切换方法和装置。

背景技术

微内核是目前在对安全要求比较高的实时操作系统领域广泛使用的内核架构。其特点是系统复杂性较小，安全可信且具备实时性。相较于宏内核，微内核提供的系统调用颗粒度小，功能单一，经常作为微核上层服务，作为构建复杂接口的功能函数来使用。

基于微内核的系统通常由多个系统调用/PRC来组成在宏内核中一次系统调用完成的任务，上下文切换频率和次数较宏内核数量多。为了解决微内核系统调用/PRC次数多导致的性能下降，通常是通过减少系统调用次数或者缩短系统调用流程来补偿，但未曾有通过减少上下文切换开销来补偿的方案。

发明内容

本申请实施例提供了一种操作系统内核切换方法和装置，面向精简指令集架构的场景，在该场景下保存/恢复寄存器一般需要几十条指令来完成。因此，在本申请实施例中，根据中断类型和操作系统对寄存器的实际使用情况，通过提供定制的上下文切换来减少需要保存和恢复的寄存器类型和数量，从而降低系统调用响应时间，减少调度延时。

第一方面，本申请实施例提供了一种操作系统内核切换方法，其中，操作系统管理多个寄存器，该方法包括：在操作系统的内核中提供多组上下文保存/恢复程序；其中每组上下文保存/恢复程序用于保存不同数量的寄存器；接收上下文切换的请求；根据该上下文切换请求获取当前上下文切换场景和当前上下文切换需要识别的用户态代码；根据上下文切换场景和识别的用户态代码，确定执行该上下文切换需要保存/恢复的寄存器集合；根据寄存器集合中的寄存器个数，从多组上下文保存/恢复程序中，选择一组上下文保存/恢复程序在内核中保存/恢复该寄存器集合中的寄存器；其中，选择的上下文保存/恢复程序能够保存的寄存器的个数大于等于寄存器集合中的寄存器的个数。

也就是说，在本申请实施例提供的一种操作系统内核切换方法，主要面向精简指令集架构场景。通过预先对内核代码进行编译，使得可以在内核中提供多种上下文保存/恢复程序，其中每一组上下文保存/恢复程序可以保存不同数量的寄存器。当系统发生上下文切换时，可以根据当前的上下文切换场景以及需要进行上下文切换的当前程序的用户态代码确定执行该上下文切换需要用保存/恢复的寄存器集合，然后选择一组上下文保存/恢复程序保存该寄存器中的寄存器。即在本申请实施例中，根据中断类型和操作系统对寄存器的实际使用情况，通过提供定制的上下文切换来减少需要保存和恢复的寄存器类型和数量，从而降低系统调用响应时间，并减少调度延时。

在一个可能的实现方式中，当前上下文切换场景为信号处理场景，上下文切换请求为系统调用请求；根据上下文切换场景和识别的用户态代码，确定执行上下文切换需要保存/恢复的寄存器集合包括：接收系统调用请求，并对系统调用者的权限进行检查；基于系统调用者具有权限，识别用户态代码；根据识别的用户态代码信息将系统调用的上下文分为第一类寄存器集合和第二类寄存器集合；其中，第一类寄存器集合中的寄存器为需要在内核保存的寄存器，第二类寄存器集合中的寄存器为不需要在内核中保存的寄存器。

也就是说，在进行系统调用时，只需要将部分寄存器保存到内核中，减少了内核在执行系统调用时的上下文保存/恢复开销。

在一个可能的实现方式中，根据所述寄存器集合中的寄存器个数，从多组上下文保存/恢复程序中，选择一组上下文保存/恢复程序在内核中保存/恢复寄存器集合中的寄存器包括：

根据第一类寄存器集合中的寄存器个数，从多组上下文保存/恢复程序中选择一组上下文保存/恢复程序在内核中保存/恢复第一寄存器集合中的寄存器。

也就是说，在操作系统内核中提供多组不同长度的保存/恢复上下文的程序，允许系统调用根据实际寄存器使用情况，选择更优的上下文保存/恢复策略。

在一个可能的实现方式中，该方法还包括：在用户态保存第二类寄存器集合中的寄存器。

也就是说，将部分寄存器放到用户态进行保存，减少了内核在执行系统调用时的上下文保存/恢复开销。

在一个可能的实现方式中，用户态代码为系统调用入口处的汇编代码；在通过编译器进行编译时，将执行系统调用需要保存/恢复的寄存器信息作为系统调用参数编码进系统调用入口处的汇编代码中。

也就是说，在进行上下文切换之前，可以指定当前上下文切换需要用到的寄存器集合。

在一个可能的实现方式中，当前上下文切换场景为信号处理场景，根据上下文切换场景和识别的用户态代码，确定执行上下文切换场景需要保存/恢复的寄存器集合包括：获取在将信号处理程序注册到内核时，传入内核的寄存器信息；该寄存器信息是指调用所述信号处理程序时，在程序的入口处需要保存/恢复的寄存器集合；根据该寄存器的集合信息确定上下文切换需要保存/恢复的寄存器集合。

在一个可能的实现方式中，当前上下文切换场景为中断处理场景，根据上下文切换场景和识别的用户态代码，确定执行上下文切换场景需要保存/恢复的寄存器集合包括：获取在将中断处理程序注册到内核时，传入内核的寄存器信息；该寄存器信息是指调用中断处理程序时，在程序的入口处需要保存/恢复的寄存器集合；根据该寄存器的集合信息确定上下文切换需要保存/恢复的寄存器集合。

在一个可能的实现方式中，当前上下文切换场景为远程过程调用场景，根据上下文切换场景和识别的用户态代码，确定执行上下文切换场景需要保存/恢复的寄存器集合包括：获取在将远程过程调用处理程序注册到内核时，传入内核的寄存器信息；该寄存器信息是指调用远程过程调用处理程序时，在程序的入口处需要保存/恢复的寄存器集合；根据该寄存器的集合信息确定上下文切换需要保存/恢复的寄存器集合。

也就是说，对于信号处理场景、中断处理场景或者远程过程调用场景，在编写远程过程调用处理程序/信号处理程序/中断处理程序时，可以通过指定的代码hint来增加该处理程序在执行过程中所需要用到的寄存器信息，并将该信息编码进内核调用远程过程调用处理程序、信号处理程序或中断处理程序的入口处。使得在执行远程过程调用处理程序、信号处理程序或中断处理程序时，可以只保存需要用到的寄存器，极大减少从内核调用到远程过程调用处理程序、信号处理程序或中断处理程序时的上下文保存/恢复开销。

在一个可能的实现方式中，用户态代码为信息处理程序、远程过程调用处理程序或者中断处理程序入口处的汇编代码；在通过编译器进行编译时，将执行信息处理程序、远程过程调用处理程序和中断处理程序需要保存/恢复的寄存器信息编码进内核调用信息处理程序、远程过程调用处理程序和中断处理程序的入口处的汇编代码中。

也就是说，在进行上下文切换之前，可以指定当前上下文切换需要用到的寄存器集合。

第二方面，本申请实施例提供了一种操作系统内核切换装置，操作系统管理多个寄存器，在操作系统的内核中提供多组上下文保存/恢复程序；其中每组上下文保存/恢复程序用于保存不同数量的寄存器，该切换装置包括：请求接收单元，用于接收上下文切换请求；目标调用确定单元，用于根据上下文切换请求获取当前上下文切换场景和当前上下文切换需要识别的用户态代码；根据上下文切换场景和识别的用户态代码，确定执行上下文切换需要用保存/恢复的寄存器集合；执行单元，用于根据寄存器集合中的寄存器个数，从多组上下文保存/恢复程序中，选择一组上下文保存/恢复程序在内核中保存/恢复所述寄存器集合中的寄存器；其中，选择的上下文保存/恢复程序能够保存的寄存器的个数大于等于寄存器集合中的寄存器的个数。

在一个可能的实现方式中，还包括：访问权限判断单元，当获取的当前上下文切换场景为系统调用场景时，请求接收单元，用于接收系统调用请求；访问权限判断单元，用于对系统调用者的权限进行检查；基于系统调用者具有权限，目标调用确定单元，用于根据识别的用户态代码信息将系统调用的上下文分为第一类寄存器集合和第二类寄存器集合；其中，第一类寄存器集合中的寄存器为需要在内核保存的寄存器，第二类寄存器集合中的寄存器为不需要在内核中保存的寄存器。

在一个可能的实现方式中，执行单元用于：根据第一类寄存器集合中的寄存器个数，从多组上下文保存/恢复程序中选择一组上下文保存/恢复程序在内核中保存/恢复第一寄存器集合中的寄存器。

在一个可能的实现方式中，执行单元还用于：在用户态保存第二类寄存器集合中的寄存器。

在一个可能的实现方式中，用户态代码为系统调用入口处的汇编代码；在通过编译器进行编译时，将执行系统调用需要保存/恢复的寄存器信息作为系统调用参数编码进系统调用入口处的汇编代码中。

在一个可能的实现方式中，当前上下文切换场景为信号处理场景，目标确定单元，还用于获取在将信号处理程序注册到内核时，传入内核寄存器信息；其中，该寄存器信息是指调用信号处理程序时，在程序的入口处需要保存/恢复的寄存器集合；根据寄存器的集合信息确定上下文切换需要保存/恢复的寄存器集合。

在一个可能的实现方式中，当前上下文切换场景为中断处理场景，目标确定单元，还用于获取在将中断处理程序注册到内核时，传入内核的寄存器信息；其中，该寄存器信息是指调用中断处理程序时，在程序的入口处需要保存/恢复的寄存器集合；根据寄存器的集合信息确定上下文切换需要保存/恢复的寄存器集合。

在一个可能的实现方式中，当前上下文切换场景为远程过程调用场景，目标确定单元，还用于获取在将远程过程调用处理程序注册到内核时，传入内核的寄存器信息；其中，该寄存器信息是指调用远程过程调用处理程序时，在程序的入口处需要保存/恢复的寄存器集合；根据寄存器的集合信息确定所述上下文切换需要保存/恢复的寄存器集合。

在一个可能的实现方式中，用户态代码为所述信息处理程序、远程过程调用处理程序或者中断处理程序入口处的汇编代码；在通过编译器进行编译时，将执行信息处理程序、远程过程调用处理程序和中断处理程序需要保存/恢复的寄存器信息编码进内核调用信息处理程序、远程过程调用处理程序和中断处理程序的入口处的汇编代码中。

第三方面，本申请实施例提供了一种计算机存储介质，计算机存储介质中存储有指令，当指令在计算机上运行时，使得计算机执行第一方面中所提供的方法。

第四方面，本申请实施例提供了一种包含指令的计算机产品，当指令在计算机上运行时，使得所述计算机执行第一方面中所提供的方法。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请实施例提供的一种微内核的操作系统结构示意图；

图2为本申请实施例提供的一种系统架构示意图；

图3为本申请实施例提供的一种操作系统内核切换方法的流程图；

图4为本申请实施例提供的一种系统调用的优化处理示意图；

图5为本申请实施例提供的又一种操作系统内核切换方法的流程图；

图6为本申请实施例提供的又一种操作系统内核切换方法的流程图；

图7为本申请实施例提供的又一种操作系统内核切换方法的流程图；

图8为本申请实施例提供的一种RPC调用的优化处理示意图；

图9为本申请实施例提供的一种用于执行操作系统内核上下文切换的装置。

具体实施方式

为了使本申请实施例的目的、技术方案和有点更加清楚，下面将结合附图，对本申请实施例中的技术方案进行描述。

在本申请实施例中的描述中，“示例性的”、“例如”或者“举例来说”的任何实施例或设计方案不应该被理解为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”、“例如”或者“举例来说”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，属于“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如A和/或B，可以表示：单独存在A，单独存在B，同时存在A和B这三种情况。另外，除非另有说明，术语“多个”的含义是指两个或两个以上。例如，多个系统是指两个或两个以上的系统，多个屏幕终端是指两个或两个以上的屏幕终端。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

由于需要限制不同的程序之间的访问能力，防止它们获取别的程序的内存数据，或者获取外围设备的数据，并发送到网络中，操作系统需要两种CPU状态，内核态和用户态。微内核是目前安全要求比较高的实时操作系统领域广泛使用的内核架构，图1为本申请实施例提供的一种微内核的操作系统结构示意图，包括用户态和内核态。其中，内核态用于运行操作系统程序，具有较高的特权级别，用户态用于运行用户程序具有较低的特权级别。运行在用户态下的程序是不能直接访问操作系统内核数据结构和程序，当在系统中执行一个程序时，大部分时间是运行在用户态下的，在其需要操作系统帮助完成某些它没有权利和能力完成的工作时就会切换到内核态。通常来说，以下情况会导致用户态到内核态的切换。

系统调用：操作系统内核为用户态提供服务的接口，系统调用的发生和返回会经历一次用户->内核->用户的过程。

异常：系统在指令执行中出现指令逻辑流中意外的情况(非法指令、缺页等)，处理器为了捕捉这种意外情况主动打断当前执行，并跳转到特定处理程序。该过程称为异常(异常处理)。

中断请求(Interrupt Request，IRQ)：指计算机系统中由硬件产生，可打断系统执行的硬件信号。系统执行中接受到中断请求时通常会立即跳转到特定的函数来处理请求。

远程过程调用(Remote-Procedure Call，RPC):在本申请实施例中特表示一个进程借助操作系统提供的机制直接调用另一个进程中的函数。

信号：操作系统提供的一种机制，由操作系统内核/进程处于某种原因(时钟到期、杀死进程)打断一个进程的执行，并告诉进程执行特定的处理程序。这个打断的请求称为信号，由信号触发的处理程序称为信号处理程序。

当操作系统收到中断、系统调用和异常信号时，会产生从内核态到用户态和用户态到内核态的切换。此时处理器产生特权级和页表的切换，从执行用户态代码切换到执行内核态代码，或相反，这个过程称为上下文切换。

本申请实施例面向精简指令集架构的场景。操作系统在进行上下文切换时，通常需要将所有的通用寄存器进行保存/恢复。由于常见精简指令集(risc)架构包含了32个通用寄存器以及多达32个浮点寄存器，且主流risc指令集上单条指令仅能保存1～2个寄存器，因此保存的执行时间不可忽略。而造成这一结果的原因是当前操作系统内核在设计时并不考虑寄存器的分配。在操作系统产生频繁上下文切换的场景，保存恢复寄存器的开销将非常可观。

特别地，当前操作系统的上下文切换业务，有如下特性：

在系统调用场景中，调用处所需要的寄存器集合可以由用户态决定，内核态不需要保存全部上下文。

在操作系统处理中断的场景中，中断处理例程通常只需要有限的上下文用于传递中断信息。

在依赖信号处理进程间通信的操作系统业务中，信号处理例程通常只需要确定有限的上下文用于传递信号信息。

在依赖远程过程调用进行进程间通信的操作系统中，RPC服务例程通常只需要确定有限的上下文用于传递RPC参数和返回值。

因此，根据场景控制上下文切换所需要的保存/恢复寄存器集合，可有效提升频繁上下文切换场景下的性能。

图2为本申请实施例提供的一种系统架构示意图，包括：用户态代码、内核代码和编译器插件。其中，编译器插件用于识别用户态代码中指定的hint，编程者可以通过用户态代码中的hint指定某一次上下文切换用到的寄存器集合。若是存在需要在用户态保存/恢复寄存器的场景，也可以由编译器在用户态代码中插入上下文恢复/保存代码。通过预先对内核态代码进行编译，使得在内核中可以提供多组不同寄存器数量的上下文保存/恢复程序，并且可以根据用户态传递的hint信息，使得由内核来指定在内核中具体使用的上下文保存/恢复流程。

本申请实施例提供了一种基于系统调用场景的操作系统内核切换方法。在本申请实施例中，在操作系统的内核代码中预先编译生成了多种可以保存不同数量的寄存器的上下文保存/恢复程序。以及借助编译器插件，提供了用户态编程中可指定的代码hint,来向内核指定上下文切换的寄存器集合，该集合信息可以作为系统调用参数编码进系统调用入口处汇编代码中。在一个示例中，可以在hint代码定义寄存器列表attribute，明确当前系统调用程序在入口处所需要保存/恢复的寄存器集合。

图3为本申请实施例提供的一种操作系统内核切换方法的流程图。当操作系统执行系统调用时，如图3所示，包括：

步骤S301，用户态程序发起系统调用。

在用户态程序发起系统调用之前，预先编译了带有hint的用户态程序。其中，在源码hint中定义了寄存器列表attribute，在attribute中明确了当前系统调用/处理程序在入口处所需要保存/恢复的寄存器集合。

在用户态程序发起系统调用以后，还需要对该系统调用者的权限进行检查。内核提供用户空间程序与内核空间进行交互的一套标准接口，这些接口让用户态程序能够受限访问硬件设备，比如申请系统资源，操作设备读写，创建新进程等。用户空间发生请求，内核空间负责执行，这些接口便是用户空间和内核空间共同识别的桥梁。

进一步地，可以在用户空间和内核空间之间设置一个叫做Syscall(system call)的中间层，作为连接用户态和内核态的桥梁。这样即提高了内核的安全型，也便于移植，只需实现同一套接口即可。在一个可能的示例中，针对Linux系统用户空间通过向内核空间发出Syscall，产生软中断，从而让程序陷入内核态，执行相应的操作。对于每个系统调用都会有一个对应的系统调用号。

步骤S302，用户态保存寄存器。

带有hint的系统调用经过编译后，将当前系统调用的上下文分为两类寄存器集合：内核需要的寄存器集合和内核不需要的寄存器集合。在用户态将内核不需要的寄存器进行保存。

步骤S303，同步系统调用。

步骤S304，内核态保存寄存器。

在内核中提供了多组可以保存不同寄存器数量的上下文保存/恢复程序，当用户空间的应用程序通过系统调用进入内核空间时，用户空间的进程处理将系统调用需要的变量、参数值传递给内核以外，还需要将当前系统调用的系统调用号和内核态需要保存的寄存器集合传递给内核。内核根据系统调用的系统调用号和已经编码在内核中的系统调用信息，选择一个寄存器保存/恢复程序保存内核需要的寄存器。在一个示例中，可以通过定义一个汇编宏SAVE_ALL，来将需要保存的寄存器保存到栈顶。

需要说明的是，在内核中提供了多组上下文保存/恢复程序，每一组上下文保存/恢复程序可以保存不同数量的寄存器。当系统调用进入内核时，内核可以根据当前系统调用需要保存/恢复的寄存器的数量来选择符合上下文保存/恢复程序。使得使用尽可能少的指令就能保存一次系统调用所需要保存的寄存器，有效缩短了保存的执行时间。

步骤S305，内核态处理。

在内核态保存完寄存器以后，内核进程还需要检查系统调用号是否是一个有效值，如果不是则退出系统调用。如果传入内核的系统调用号是一个有效值，内核进程根据系统调用号在系统调用表中找到相应的内核函数执行。

步骤S306，内核态恢复寄存器。

在一个可能的示例中，系统调用处理完成以后，可以由恢复上下文过程把保存上下文过程压入的寄存器反向弹出。

步骤S307，系统调用返回。

步骤S308，用户态恢复寄存器。

在用户态将之前保存的寄存器进行恢复。

步骤S309，返回用户态代码。

在本申请实施例中，通过在用户态代码中指定当前系统调用需要保存/恢复的寄存器组来使得系统调用在进入内核时，在内核态中只保存需要的寄存器。即通过定制的上下文切换来减少需要保存和恢复的寄存器类型和数量，从而降低系统调用响应时间，并减少调度延时。进一步地，通过在操作系统内核中提供多组不同长度的保存/恢复上下文的程序，允许系统调用、中断处理、信号处理、RPC根据实际寄存器使用情况，选择更优的上下文保存/恢复策略。

图4为本申请实施例提供的一种系统调用的优化处理示意图。在如图4所示的实现形态是包含在编译器、源码hint和操作系统上下文中的代码，包括编译器插件代码和运行时代码两个组成部分。编译器插件将读入C代码定义的寄存器列表attribute，在attribute中明确了当前系统调用/处理程序在入口处所需要保存/恢复的寄存器集合。

在编译阶段，编译器识别到调用的系统调用原型已定义hint，在生成汇编代码时，将系统调用attribute中的寄存器集合信息作为系统调用参数编码进系统调用的入口汇编代码中，将系统调用不需要的寄存器留在用户态进行保存恢复。

在执行阶段，内核进程根据系统调用号选择需要使用的上下文切换过程。在内核中提供了多组上下文保存/恢复程序，每一组上下文保存/恢复程序可以保存不同数量的寄存器。当系统调用进入内核时，内核进程可以根据当前系统调用需要保存/恢复的寄存器的数量来选择符合上下文保存/恢复程序。

在一个示例中，在如图4所示的系统调用过程中，内核提供了三组上下文保存/恢复程序。其中，第一组上下文保存/恢复程序可以保存/恢复的寄存器数量为1个，第二组上下文保存/恢复程序可以保存/恢复的寄存器的数量为4个，第三组上下文保存/恢复程序可以保存/恢复的寄存器数量为8个。当编译器读入的C代码定义的寄存器列表attribute中包括3个寄存器时，内核进程根据当前系统调用需要保存的寄存器数量选择第二组上下文保存/恢复程序来保存寄存器列表attribute中的3个寄存器。

在一个可能的实施例中，本申请实施例在ARMv8架构上实现。ARMv8架构上有30个通用寄存器，4个程序状态相关寄存器，一次常规上下文切换需要保存/恢复多达34个长度为64bit的寄存器。在系统调用之前进行系统调用原型定义。在一个示例中，在hint中定义寄存器列表attribute，在attribute中明确了当前系统调用/处理程序在入口处所需要保存/恢复的寄存器集合。系统调用原型定义hint如下：

int_attribute_((sys_reglist(“X0,X1,X2”)))

syscall_sys_futex(void*arg1,int arg2)；

然后在用户态系统调用发生处通过调用syscall_sys_futex系统调用进入内核模式。即在用户态系统调用发生处的代码为：

…

ret＝syscall_sys_futex(ptr,arg)；

…

将用于系统调用的用户态代码通过编译器插件进行编译，得到编译后的用户态代码如下：

…

Push x3～x15

Mov r0,SVC_NO_OF_SYS_FUTEX

Idr r1,[ADDR_OF arg1]

Idr r2,[ADDR_OF arg2]

Svc

Pop r3～r5

内核系统调用代码如下：

…

bl save_x0_to_x2

bl syscall_entry

bl restore_x0_to_x2

eret

在编译期，编译器识别到调用的系统调用原型hint，指定在内核中只用到X0到X2三个寄存器，生成的用户态代码中将违背原有平台定义的调用约定(callingconvension)，在实际调用svc的前后，在用户态保存恢复内核所不需要的寄存器。

内核在编写过程中，编译器识别到系统调用的原型定义hint，为当前系统调用的入口生成的代码前后选择特定的上下文恢复调用，只保存恢复x0到x2这三个寄存器。

在本申请是实施例中，在用户态系统调用发生时，将直接走到指定的内核上下文保存恢复流程，从而确保了内核路径极大缩短。

本申请实施例还提供了一种基于RPC场景/信号处理场景/中断处理场景的操作系统内核切换方法，需要说明的是，RPC在本申请实施例中特表示一个进程借助操作系统提供的机制直接调用另一个进程中的函数。在本申请实施例中，在操作系统的内核代码中预先编译生成了多种可以保存不同数量的寄存器的上下文保存/恢复程序，以及在编写RPC处理程序/信号处理程序/中断处理程序时，可以通过指定的代码hint来增加该处理程序在执行过程中所需要用到的寄存器信息，并将该信息编码进内核调用RPC处理程序、信号处理程序或中断处理程序的入口处。通过在操作系统内核中提供多组不同长度的保存/恢复上下文的程序，允许系统调用、中断处理、信号处理、RPC根据实际寄存器使用情况，选择更优的上下文保存/恢复策略。

图5为本申请实施例提供的又一种操作系统内核切换方法的流程图，当操作系统执行RPC处理时，包括：

步骤S501，用户态程序发起系统调用。

步骤S502，用户态保存寄存器。

步骤S503，同步系统调用。

步骤S504，内核态保存寄存器。

步骤S505，内核态处理。

步骤S5051，内核态恢复寄存器。

当内核主动调用一段RPC处理程序时，在内核态中需要保存当前正在执行的进程的上下文，以及需要在内核态中恢复部分寄存器用于在RPC处理过程中传递参数。具体地，由于预先将带有hint的RPC处理程序注册到了内核中，因此内核进程可以根据RPC处理程序在内核态注册RPC过程时传入的寄存器集合信息，在内核态恢复一定数量的寄存器。

在一个可能的示例中，内核进程在恢复寄存器时，可以根据hint中的寄存器的个数信息从内核中选择一组上下文保存/恢复程序用于恢复寄存器。其中，选择的上下文保存/恢复程序能够保存的寄存器的个数大于等于hint中的寄存器的个数。

步骤S5052，在用户态中执行RPC处理。

步骤S5053，在内核态保存寄存器。

当在用户态执行完RPC处理程序时，还需要将部分参数传递回内核态，此时内核进程可以根据hint中的寄存器的个数信息从内核中选择一组上下文保存/恢复程序用于保存寄存器及将返回的参数存储到寄存器中。

在一个可能的示例中，当远程过程调用完成以后，内核可以执行其他进程，也可以继续执行在执行远程过程调用时中断的进程。当内核继续执行在执行远程过程调用时中断的进程时，还包括步骤S506-步骤S509。

步骤S506，内核态恢复寄存器。

步骤S507，系统调用返回。

步骤S508，用户态恢复寄存器。

步骤S509，返回用户态代码。

在本申请实施例中，当发生RPC调用时，绝大多数情况下绝大多数情况下内核只需要用到少量寄存器用于传参，并不需要使用所有的寄存器。因此本申请实施例，内核在出内核态调用RPC过程前，先读入需要恢复的寄存器编码信息，然后根据读出的值选择对应的寄存器恢复程序，以及在执行完RPC过程以后返回到内核态时，根据读出的值选择对应的寄存器保存程序。可以极大减少从内核调用到RPC处理程序时的上下文恢复/保存开销。

图6为本申请实施例提供的又一种操作系统内核切换方法的流程图。当操作系统执行中断处理时，其处理流程包括：

步骤S601，接收中断信号；

步骤S602，响应于该中断信号，在内核态保存/恢复寄存器，并跳转至中断服务程序；

接收到中断信息以后，需要将当前被暂停执行的程序的上下文进行保存，以及需要在内核态中恢复部分寄存器用于在中断处理过程中传递参数。具体地，由于预先将带有hint的中断处理程序注册到了内核中，因此内核进程可以根据该处理程序在内核态注册该过程时传入的寄存器集合信息，在内核态恢复一定数量的寄存器。其中恢复的寄存器的个数大于等于hint中的寄存器的个数。

在一个可能的示例中，内核进程在恢复寄存器时，可以根据hint中的寄存器的个数信息从内核中选择一组上下文保存/恢复程序用于恢复寄存器。

在一个可能的示例中，针对risc-v架构芯片。在risc-v中，对于rv32i这一基础指令集，需要保存诸如ra、gp、tp、t0-t2等通用寄存器与mstatus、mepc等处理器状态寄存器。当中断发生时，mepc中保存的是中断处理后应该恢复执行的位置。

步骤S603，执行中断服务程序；

步骤S604，在内核态保存/恢复寄存器。

当中断服务程序执行完成以后，需要将部分参数传递回内核态，此时内核进程可以根据hint中的寄存器的个数信息从内核中选择一组上下文保存/恢复程序用于保存寄存器及将返回的参数存储到寄存器中。

在中断服务程序执行完成以后，还需要对在执行中断服务时，被暂停的进程的上下文进行恢复，并继续执行该进程。

在一个可能的示例中，针对risv-v架构，在恢复现场的时候，只需要调用mret指令就能够恢复之前的处理器状态。

图7为本申请实施例提供的又一种操作系统内核切换方法的流程图。当操作系统进行信号处理时，其处理流程包括：

步骤S701，接收信号。

步骤S702，响应于该信号，在内核态保存/恢复寄存器。

信号被认为是一种软件中断(区别于硬件中断)。信号机制提供了一种在单进程或者线程下处理异步事件的方法。具体过程是当进程运行到某处，接受到一个信号，保存当前正在执行的进程的上下文以后，执行信号处理程序。

在执行信号处理程序之前，需要在内核态中恢复部分寄存器用于在信号处理过程中传递参数。具体地，由于预先将带有hint的中断处理程序注册到了内核中，因此内核进程可以根据该处理程序在内核态注册该过程时传入的寄存器集合信息，在内核态恢复一定数量的寄存器。其中恢复的寄存器的个数大于等于hint中的寄存器的个数。

在一个可能的示例中，内核进程在恢复寄存器时，可以根据hint中的寄存器的个数信息从内核中选择一组上下文保存/恢复程序用于恢复寄存器。

步骤S703，执行信号处理程序。

步骤S704，在内核态保存/恢复寄存器。

当信号处理程序执行完成以后，需要将部分参数传递回内核态，此时内核进程可以根据hint中的寄存器的个数信息从内核中选择一组上下文保存/恢复程序用于保存寄存器及将返回的参数存储到寄存器中。

在信号处理程序执行完成以后，还需要对在执行信号处理程序时，被暂停的进程的上下文进行恢复，并继续执行该进程。

图8为本申请实施例提供的一种RPC调用的优化处理示意图。在如图8所示的实现形态是包含在编译器、源码hint和操作系统上下文中的代码，包括编译器插件代码和运行时代码两个组成部分。编译器插件将读入C代码定义的寄存器列表attribute，在attribute中明确了当前系统调用/处理程序在入口处所需要保存/恢复的寄存器集合。对于信号处理、RPC处理和中断处理，该信息将编码进内核调用这些过程的入口。

在一个可能的实施例中，在编译阶段，编译器识别到RPC处理程序已定义的hint，如图8所示，在定义的hint信息中指定在内核中用到X0到X2三个寄存器，生成的用户态代码中，将内存器使用信息编码进处理程序头两个字节。

在执行阶段，内核进程根据处理函数的注册信息，由内核切换到用户态调用处理函数时，选择对应的上下文切换过程。在内核中提供了多组上下文保存/恢复程序，每一组上下文保存/恢复程序可以保存不同数量的寄存器。信号处理、RPC处理程序和中断处理将根据用户态注册这些过程时传入的寄存器集合信息，在跳转到用户态以及跳转回内核态时选择指定的保存/恢复上下文流程。

在一个示例中，在如图6所示的信号处理、RPC和终端处理过程中，内核提供了三组上下文保存/恢复程序。其中，第一组上下文保存/恢复程序可以保存/恢复的寄存器数量为1个，第二组上下文保存/恢复程序可以保存/恢复的寄存器的数量为4个，第三组上下文保存/恢复程序可以保存/恢复的寄存器数量为8个。当编译器读入的C代码定义的寄存器列表attribute中包括3个寄存器时，内核进程根据当前系统调用需要保存的寄存器数量选择第二组上下文保存/恢复程序来保存寄存器列表attribute中的3个寄存器。

在一个可能的实施例中，本申请实施例提供的远程过程调用处理在ARMv8架构上实现。ARMv8架构上有30个通用寄存器，4个程序状态相关寄存器，一次常规上下文切换需要保存/恢复多达34个长度为64bit的寄存器。

在编译期，编译器识别早RPC处理程序入口处已定义的hint。其中在RPC入口处定义的hint代码为：

int

_attribute_((kcall_reglist(“x0,x1,x2”)))

_attribute_((kcall_ret_reglist(“x0”)))

sys_handler_1(void*arg1,intarg2){

…

…

return ret；

}

通过编译器插件编译以后的RPC处理程序的hint代码为：

sys_handler_1:

b sys_handler_1_entry

.long 0x3//调用寄存器x0 x1 x2

.long 0x1//返回使用的寄存器x0

sys_handler_1_entry；

…

svc//Back to kernel

内核在出用户态调用RPC过程前，先读入需要恢复的寄存器编码信息，然后根据度出的值选择对应的寄存器恢复程序。其中，内核调用RPC处理程序代码为：

Idr x0,[ADDR_OF sys_handler_1+0x4]

bl restore_regs

Idr elr,[ADDR_OF sys_handler_1]

eret

当发生PRC调用时，绝大多数情况下内核只需要用到少量寄存器用于传递参数，并不需要使用所有的寄存器。在本申请实施例中，在RPC处理程序入口处已定义的hint代码中指定了需要用到的寄存器的个数，使得在执行PRC处理程序时，可以只保存需要用到的寄存器，极大减少了从内核调用到RPC处理程序时的上下文恢复/保存开销。

在本申请实施例中，还提供了一种信号处理和用户态中断处理场景下的上下文切换，其处理过程和RPC处理过程相同，在此，不再赘述。

本申请实施例还提供了一种用于执行操作系统内核上下文切换的装置，如图9所示，包括：请求接收单元901、目标调用单元902、执行单元903。

请求接收单元901用于接收上下文切换请求。

目标调用确定单元902用于获取当前上下文切换的场景，根据当前上下文切换场景和识别的用户态代码，确定执行所述上下文切换需要用保存/恢复的寄存器集合；

执行单元903用于执行所述上下文切换请求，并利用上下文保存/恢复程序在内核态中保存所述寄存器集合。

其中,获取的上下文切换场景包括:系统调用场景、信号处理场景、中断处理场景、远程过程调用场景中的至少一种。

在一个示例中，当获取的上下文切换场景为系统调用场景时，执行单元903可以用于执行步骤S303-步骤S309。

在一个示例中，当获取的上文切换场景为远程过程调用场景时，执行单元903可以用于执行步骤S5051-步骤S509。

在一个示例中，当获取的上文切换场景为中断处理场景时，执行单元903可以用于执行步骤S602-步骤S604。

在一个示例中，当获取的上文切换场景为信号处理场景时，执行单元903可以用于执行步骤S702-步骤S704。

本申请的实施例中的方法步骤可以通过硬件的方式来实现，也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable rom，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。