多核异构平台下信息交互的内存申请方法、装置及设备与流程

本申请涉及数据处理领域，具体涉及一种多核异构平台下信息交互的内存申请方法、装置及设备。

背景技术：

多核异构平台至少具有两个异构的系统，以下称为第一系统和第二系统，第一系统和第二系统之间需要异步处理消息。为了实现第一系统的CPU与第二系统的CPU之间的信息交互，需要利用队列对交互的信息进行缓存处理。

而在实现多核异构平台下的信息交互之前，存在信息交互的两个CPU需要具有对应的申请队列和释放队列，以实现信息交互过程中对内存的申请和释放功能。

目前，多核异构平台中每对存在信息交互的CPU至少需要执行信息交互中的内存申请任务，由于存在异构平台下信息交互的CPU可能有多对，而每对CPU均需要执行内存申请任务，显然会消耗各个CPU自身的性能，从而导致多核异构平台整体性能下降。

技术实现要素：

有鉴于此，本发明提供了一种多核异构平台下信息交互的内存申请方法、装置及设备。

第一方面，本发明提供了一种多核异构平台下信息交互的内存申请方法，所述多核异构平台包括异构的第一系统和第二系统，所述第一系统运行有队列维护CPU和至少一个第一CPU，所述第二系统运行有至少一个第二CPU，所述方法应用于所述队列维护CPU，所述方法包括：

根据内存需求申请内存；其中，所述内存需求来自与任一第一CPU存在信息交互的第二CPU；

将所述内存加入到预先建立的申请队列中，以便所述第二CPU从所述申请队列中获取所述内存。

可选的，所述方法还包括：

轮询从预先建立的释放队列中读取内存，并将所述内存进行释放；其中，所述内存由所述第二CPU加入所述释放队列。

可选的，所述内存需求中携带有申请队列类型标识；在所述队列维护CPU将所述内存加入到预先建立的申请队列中之前，还包括：

根据所述申请队列类型标识，建立与所述第二CPU具有对应关系的申请队列，并向所述第二CPU返回所述申请队列的队列标识；其中，所述申请队列的队列标识用于确定所述申请队列。

可选的，至少两个第二CPU与所述申请队列具有对应关系；所述方法还包括：

向所述至少两个第二CPU返回所述申请队列的队列标识，以便所述至少两个第二CPU根据所述队列标识从所述申请队列中获取内存。

可选的，每个第二CPU分别对应于一个申请队列。

可选的，在所述队列维护CPU从预先建立的释放队列中读取内存，并将所述内存进行释放之前，还包括：

建立对应于所述第二CPU的释放队列，并向所述第二CPU返回所述释放队列的队列标识；其中，所述释放队列的队列标识用于确定所述释放队列。

可选的，每个第二CPU分别对应于一个释放队列。

可选的，所述释放队列为所述至少一个第二CPU通用的释放队列；在所述队列维护CPU从预先建立的释放队列中读取内存，并将所述内存进行释放之前，还包括：

向所述至少一个第二CPU返回所述释放队列的队列标识。

可选的，所述方法还包括：

从预先建立的释放队列中读取内存，将所述内存加入至任一申请队列中；其中，所述内存由所述第二CPU加入所述释放队列。

可选的，所述申请队列设置有对应的变量指针，所述变量指针用于存储所述第二CPU向所述第一CPU发送失败的消息所占的内存，所述内存的优先级高于所述申请队列中的内存。

可选的，所述方法还包括：

轮询各个申请队列，以确定各个申请队列中的内存是否满足预设条件；

在确定任一申请队列中的内存未满足所述预设条件时，向所述申请队列中添加内存。

第二方面，本发明还提供了一种多核异构平台下信息交互的内存申请装置，所述多核异构平台包括异构的第一系统和第二系统，所述第一系统运行有所述装置和至少一个第一CPU，所述第二系统运行有至少一个第二CPU，所述装置包括：

申请模块，用于根据内存需求申请内存；其中，所述内存需求来自与任一第一CPU存在信息交互的第二CPU；

第一加入模块，用于将所述内存加入到预先建立的申请队列中，以便所述第二CPU从所述申请队列中获取所述内存。

可选的，所述装置还包括：

释放模块，用于轮询从预先建立的释放队列中读取内存，并将所述内存进行释放；其中，所述内存由所述第二CPU加入所述释放队列。

可选的，所述内存需求中携带有申请队列类型标识；所述装置还包括：

第一建立模块，用于根据所述申请队列类型标识，建立与所述第二CPU具有对应关系的申请队列，并向所述第二CPU返回所述申请队列的队列标识；其中，所述申请队列的队列标识用于确定所述申请队列。

可选的，至少两个第二CPU与所述申请队列具有对应关系；所述装置还包括：

第一返回模块，用于向所述至少两个第二CPU返回所述申请队列的队列标识，以便所述至少两个第二CPU根据所述队列标识从所述申请队列中获取内存。

可选的，每个第二CPU分别对应于一个申请队列。

可选的，所述装置还包括：

第二建立模块，用于建立对应于所述第二CPU的释放队列，并向所述第二CPU返回所述释放队列的队列标识；其中，所述释放队列的队列标识用于确定所述释放队列。

可选的，每个第二CPU分别对应于一个释放队列。

可选的，所述释放队列为所述至少一个第二CPU通用的释放队列；所述装置还包括：

第二返回模块，用于向所述至少一个第二CPU返回所述释放队列的队列标识。

可选的，所述装置还包括：

第二加入模块，用于从预先建立的释放队列中读取内存，将所述内存加入至任一申请队列中；其中，所述内存由所述第二CPU加入所述释放队列。

可选的，所述申请队列设置有对应的变量指针，所述变量指针用于存储所述第二CPU向所述第一CPU发送失败的消息所占的内存，所述内存的优先级高于所述申请队列中的内存。

可选的，所述装置还包括：

轮询模块，用于轮询各个申请队列，以确定各个申请队列中的内存是否满足预设条件；

添加模块，用于在确定任一申请队列中的内存未满足所述预设条件时，向所述申请队列中添加内存。

第三方面，本发明还提供了一种多核异构平台下信息交互的内存申请设备，所述设备包括存储器和处理器，

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于运行所述程序代码，其中，所述程序代码运行时执行上述任一项所述的多核异构平台下信息交互的内存申请方法。

本申请提供的多核异构平台下信息交互的内存申请方法中，多核异构平台包括异构的第一系统和第二系统，第一系统运行有队列维护CPU和至少一个第一CPU，第二系统运行有至少一个第二CPU，该方法应用于队列维护CPU，具体的，队列维护CPU接收来自与任一第一CPU存在信息交互的第二CPU的内存需求，根据该内存需求申请内存，并将内存加入到预先建立的申请队列中，以便该第二CPU从申请队列中获取该内存。本申请中由队列维护CPU单独为与任一第一CPU存在信息交互的各个第二CPU申请内存，其他CPU无需参与，大大减少了多核异构平台中其他CPU性能的损耗。

附图说明

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

图1为本发用实施例提供的一种多核异构平台的系统示意图；

图2为本发明实施例提供的一种多核异构平台下信息交互的内存申请方法的流程图；

图3为本发明实施例提供的一种申请队列建立方法的流程图；

图4为本发明实施例提供的一种释放内存的方法流程图；

图5为本发明实施例提供的一种释放队列建立方法的流程图；

图6为本发明实施例提供的另一种多核异构平台下信息交互的内存申请方法的流程图；

图7为本发明实施例提供的一种多核异构平台下信息交互的内存申请装置的结构示意图；

图8为本发明实施例提供的另一种多核异构平台下信息交互的内存申请装置的结构示意图；

图9为本发明实施例提供的一种多核异构平台下信息交互的内存申请设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

多核异构平台至少具有两个异构的系统，在本申请实施例中，多核异构平台中包括第一系统和第二系统，并且多核异构平台中的第一系统和第二系统之间需要异步处理消息。当第一系统和第二系统之间存在信息交互时，需要利用队列对交互的信息进行缓存。

以基于多核异构平台的网络转发系统为例，网络转发系统中包括异构的快速转发逻辑模块和慢速处理模块，其中，快速转发逻辑模块中运行有多个CPU，慢速处理模块中也运行有多个CPU，并且两个模块中的CPU之间能够进行信息交互，例如，快速转发逻辑模块中的CPU1和慢速处理模块中的CPU2之间可以进行信息交互。需要说明的是，快速转发逻辑模块中的CPU一般运行于用户态，主要负责从网卡接收报文并实现快速转发，而慢速处理模块中的CPU一般运行于内核态，主要实现功能复杂的逻辑。

通常情况下，在进行报文转发的过程中，用户态CPU从网卡中接收需要转发的报文，查询用户态CPU中是否存在session会话表，若在用户态CPU中查找到session会话表，可直接基于该session会话表转发报文；若在用户态CPU中查找不到session会话表，则需要用户态CPU新建session会话表以实现报文转发，具体建立session会话表时，需要将报文转发至内核态CPU进行策略匹配，内核态CPU将匹配的策略返回至用户态CPU，以便用户态CPU可以基于该返回的策略快速建立session会话表，并基于该session会话表进行报文转发。

在上述用户态CPU建立session会话表的过程中，由于用户态CPU和内核态CPU处于异构平台的两个不同的系统中，用户态CPU至少需要向内核态CPU发送mbuf消息和作为策略媒介的sess_info消息，内核态CPU将策略信息填入sess_info后，进一步，向用户态CPU返回mubf消息和sess_info消息，以便用户态CPU建立session会话表，其中，mubf消息和sess_info消息作为session会话表建立过程中必不可少的参数类型，需要为mubf消息和sess_info消息申请内存。

在session会话表建立过程中，用户态CPU需要为发送至内核态CPU的mubf消息和sess_info消息申请内存，并将mubf消息和sess_info消息发送至内核态CPU，相应地，内核态CPU向用户态CPU返回mubf消息和sess_info消息后，用户态CPU需要将mubf消息和sess_info消息的内存进行释放。基于此，该网络转发系统至少需要设计用户态CPU到内核态CPU的allocsess_info队列和alloc mubf队列，以及用户态CPU自身的free sess_info队列和free mubf队列，具体的，用户态CPU将为mubf消息和sess_info消息申请的内存分别填入alloc sess_info队列和alloc mubf队列，将需要释放的mubf消息和sess_info消息的内存分别填入free mubf队列和free sess_info队列。

此外，网络转发系统中还可能存在用户态CPU向内核态CPU发送报文，不需要内核态返回报文的情况，以及内核态CPU主动向用户态CPU发送报文的情况。在这些情况下，网络转发系统至少还需要设计内核态CPU到用户态CPU的alloc sess_info队列和alloc mbuf队列，以及内核态CPU自身free sess_info队列和free mbuf队列，内核态CPU可以将为sess_info消息和mubf消息申请的内存分别填入alloc sess_info队列和alloc mbuf队列，将需要释放的sess_info消息和mubf消息的内存分别填入free sess_info队列和free mbuf队列。

综上所述，现有技术中网络转发系统需要为具有信息交互的用户态CPU和内核态CPU至少设计上述8个队列，此外至少还需要在用户态CPU和内核态CPU之间设计1对用于报文处理的队列，并且，用户态CPU和内核态CPU在信息交互的过程中，每增加一个需要传递的参数类型，则至少需要相应地增加1对针对于该参数类型的申请和释放队列。

也就是说，在具有信息交互的两个CPU之间需要建立大量的申请队列和释放队列，大量队列的维护工作对于每个CPU而言也是一项不小的工程，并且随着队列数量的增加，bug产生的几率也会相应地增加。此外，每个CPU对应多少个队列，该CPU在工作的过程中就需要轮询多少个队列，在轮询的过程中即使有队列为空，该CPU仍需要对该队列进行轮询，CPU对与之对应的队列如此轮询下来会耗费大量性能。

为了解决上述现有技术中存在的技术问题，本申请提供了一种多核异构平台下信息交互的内存申请方法，由单独的队列维护CPU轮询具有信息交互的CPU之间的队列，异构平台中的其他CPU无需执行轮询队列的工作，减少了异构平台中其他CPU因轮询队列而产生的性能损耗。此外，本申请中各申请队列以及释放队列均由队列维护CPU单独建立，而队列维护CPU建立的申请队列和释放队列可以存储对应于不同参数类型的内存，即不需要一种参数类型的内存对应一个申请队列和一个释放队列，因此，大大减少了具有异构平台信息交互的CPU之间的队列数量。

下面介绍本申请提供的多核异构平台下信息交互的内存申请方法所应用的系统结构，多核异构平台中包括有异构的第一系统和第二系统，其中，第一系统中运行有队列维护CPU和至少第一CPU，第二系统中运行有至少第二CPU。

下面结合上述应用系统结构，介绍一下本申请的发明思路：

第一系统中的队列维护CPU接收来自与任一第一CPU存在信息交互的第二CPU的内存需求，并根据内存需求建立申请队列，根据该内存需求建立的申请队列与该第二CPU之间具有对应的关系。其中，第二CPU可以为第二系统中的任意一个CPU，当第二CPU需要为待发送的消息申请内存时，即可直接从该对应的申请队列中获取内存。并且队列维护CPU建立的申请队列可以与第二系统中的多个CPU具有对应关系，也就是说，当上述多个CPU需要为待发送的消息申请内存时，均可从该申请队列中获取内存。

需要说明的是，本申请中的申请队列均是由队列维护CPU单独建立的，且不需要根据参数类型的不同建立对应于不同参数类型的申请队列，也就是说，不同参数类型的信息可以共用申请队列，所以，针对于一个CPU需要申请的对应于多种参数类型的内存，队列维护CPU可以为其建立共用的申请队列，不需要进行参数类型的区分，大大减少了具有异构平台信息交互的CPU之间的队列数量。若第二系统的CPU需要对应于不同参数类型的内存，均可从与该CPU具有对应关系的申请队列中获取，该CPU可以从该申请队列中获取到各种需要的参数类型对应的内存。

由此可见，在建立申请队列时，无需根据参数类型的不同，为一个CPU建立分别与各个参数类型对应的多个申请队列，而是为该CPU建立可以与各种参数类型对应的申请队列即可，该CPU可以通过该申请队列获取对应于各参数类型的内存，减少了申请队列的数量。进一步的，本申请提供的技术方案，对于第二系统内的多个CPU，也可以使用同一个申请队列申请对应于各个参数类型的内存，进一步减少了申请队列的数量。

此外，队列维护CPU还可以建立对应于第二CPU的释放队列，该释放队列与第二CPU之间具有对应关系，当第二CPU需要释放内存时，即可将需要释放的内存填入该释放队列中。另外，队列维护CPU还可以建立对应于第二系统中所有CPU的通用释放队列，第二系统中所有的CPU均可将需要释放的内存填入该通用释放队列。

与上述申请队列相类似，本申请中的释放队列均由队列维护CPU建立，且不需要根据参数类型的不同，建立对应于不同参数类型的释放队列，即当第二系统的CPU需要释放对应于不同参数类型的内存时，均可从与该CPU具有对应关系的释放队列释放内存。

由此可见，在建立释放队列时，无需根据参数类型的不同，为一个CPU建立与各个参数类型对应的各个释放队列，即本申请提供的技术方案对于第二系统中的一个CPU，仅需要为该CPU建立一个释放队列，该CPU将需要释放的内存填入该释放队列中即可，大大减少了释放队列的数量。进一步的，本申请提供的技术方案，还可以对于第二系统内的所有CPU，仅建立一个通用释放队列，即第二系统内的所有CPU均可将需要释放的内存填入该通用释放队列，又进一步减少了释放队列的数量。

在本申请中，由队列维护CPU单独对各个队列进行轮询，由于本申请中队列的数量大大减少，所以，队列维护CPU轮询队列需要消耗的性能也大大减少，一定程度上提高了系统的整体性能。

在第一CPU和第二CPU进行信息交互的过程中，队列维护CPU会根据第二CPU的内存需求，从位于第一系统的内存池中申请内存，并将该申请的内存加入预先建立的申请队列中，以便于第二CPU从该申请队列中获取内存。当第二CPU需要释放内存时，会将需要释放的内存填入与该第二CPU对应的释放队列中，队列维护CPU读取释放队列中的内存后进行释放。

根据上述对申请队列和释放队列建立过程的介绍可知，相比于现有技术中用于实现多核异构平台下的信息交互所需的申请队列和释放队列的数量，本申请中申请队列和释放队列的数量已经大大减少，很大程度上降低了系统维护工作的难度，也降低了bug产生的几率。此外，本申请中内存申请、释放以及队列轮询的工作均由队列维护CPU单独来执行，其他CPU不需要对系统中的队列进行轮询，也减少了对其他CPU性能的耗费。

实施例一

本实施例提供了一种多核异构平台下信息交互的内存申请方法，该方法应用于多核异构平台，如图1所示，为该多核异构平台的系统结构示意图。该多核异构平台包括异构的第一系统和第二系统，第一系统运行有队列维护CPU和至少第一CPU，第二系统运行有至少一个第二CPU，如图1所示，第一系统中运行有CPU0、CPU1、CPU2和CPU3等多个第一CPU，第二系统中运行有CPU4、CPU5、CPU6和CPU7等多个第二CPU，上述第一系统中的第一CPU与第二系统中的第二CPU之间存在信息交互。

本实施例提供的多核异构平台下信息交互的内存申请方法可以应用于上述多核异构平台的队列维护CPU中，该方法包括：

S201：队列维护CPU根据内存需求申请内存；其中，内存需求来自与任一第一CPU存在信息交互的第二CPU。

S202：队列维护CPU将内存加入到预先建立的申请队列中，以便第二CPU从申请队列中获取内存。

多核异构平台包括异构的第一系统和第二系统，第一系统中的CPU和第二系统中的CPU之间存在信息交互，在信息交互的过程中，对于第一系统中的CPU和第二系统中的CPU之间需要交互的内存，设计为共享内存部分，当两者需要进行交互时，只需通过队列将共享内存的地址发送给对方即可。本申请中需要交互的内存是以内存池的形式提供，由队列维护CPU从位于第一系统中的内存池获取，内存池实际上类似于一个池子，既能从中申请内存空间，也能将不用的内存空间释放回去。在第一系统中建立内存池时，需要根据第二系统中的CPU的注册需求来建立该内存池，即需要获取第二系统中CPU的注册需求，注册需求可以包括第二系统中的CPU预计需要使用多少内存，进而根据第二系统中CPU的注册需求，在第一系统中注册能够满足第二系统中CPU注册需求的内存，完成内存池的建立。

具体建立内存池时，第二系统中的CPU会向队列维护CPU发送自身的注册需求，告知队列维护CPU自身需要申请的结构体内容，并表明希望使用第一系统中哪部分内存作为共享内存空间，即作为能够从中获取内存的内存池。队列维护CPU会根据第二系统中CPU的注册需求，判断其需要作为共享内存空间的内存是否已经被申请和被初始化，若这部分内存空间未被初始化，则根据第二系统中CPU的注册需求初始化这部分内存空间作为共享内存空间，若这部分内存空间已被初始化，则可直接使用这部分内存空间作为共享内存空间。

在第一CPU和第二CPU进行信息交互的初始化过程中，队列维护CPU会根据接收到的内存需求，从位于第一系统的内存池中申请内存，并将在内存池中申请到的内存加入预先建立的申请队列中。第二CPU需要使用内存时，即可直接从申请队列中获取内存。

需要说明的是，队列维护CPU所接收的内存需求来自任一与第一系统中的第一CPU存在信息交互的第二CPU，即队列维护CPU根据与第一CPU存在信息交互的第二CPU的内存需求，在内存池中申请内存。

具体的，第二CPU的内存需求可能包括所需要的内存的大小等参数，队列维护CPU会根据第二CPU内存需求中的参数，从第一系统中的内存池申请内存，并且将申请到的内存加入预先建立的申请队列中。

本实施例提供的多核异构平台下信息交互的内存申请方法，由队列维护CPU根据第二系统中CPU的注册需求在第一系统中相应的注册内存池，在第一CPU和第二CPU需要进行信息交互的初始化过程中，队列维护CPU根据第二CPU的内存需求，从位于第一系统中的内存池中申请内存，并将申请的内存加入预先建立的申请队列中，使得第二CPU在需要获取内存的时候，可以直接从该申请队列中获取内存。本发明实施例中，内存申请以及队列轮询的工作均由队列维护CPU单独执行，异构平台中的其他CPU无需执行这些工作，因此，大大减少了多核异构平台中其他CPU性能的损耗。

在上述实施例一中，队列维护CPU将从内存池中申请的内存，加入预先建立的申请队列中，以便第二CPU从该申请队列中获取内存。其中，用于存储第二CPU所需内存的申请队列也是由队列维护CPU建立的，下面详细介绍申请队列的建立的方法。

实施例二

如图3所示，本实施例提供的一种申请队列的建立方法的流程图，该方法应用于多核异构平台，该多核异构平台包括异构的第一系统和第二系统，第一系统运行有队列维护CPU和第一CPU，第二系统运行有第二CPU，第一CPU和第二CPU之间存在信息交互，该方法包括：

S301：队列维护CPU根据申请队列类型标识，建立与第二CPU具有对应关系的申请队列；申请队列类型标识被携带在内存需求中。

S302：队列维护CPU向第二CPU返回申请队列的队列标识。

其中，第二CPU的内存需求中携带的申请队列类型标识，能够表征该第二CPU需要何种类型的申请队列。具体的，该第二CPU的内存需求中携带有单消费者的申请队列类型标识，即该第二CPU需要从唯一与其对应的申请队列中获取自身需要的内存，不能够与第二系统中的其他CPU共用申请队列，从共用的申请队列中获取自身需要的内存；此外，该第二CPU的内存需求中携带有多消费者的申请队列类型标识，即表明该第二CPU可以和第二系统中的其他CPU共用申请队列，这些CPU也可以从该共用的申请队列中获取自身需要的内存。

相应的，队列维护CPU会根据第二CPU的内存需求中携带的申请队列类型标识，建立与该第二CPU具有对应关系的申请队列，并向第二CPU返回该申请队列的队列标识，该申请队列的队列标识用于确定该申请队列。

具体的，若第二CPU的内存需求中携带有单消费者的申请队列类型标识，队列维护CPU建立的与第二CPU具有对应关系的申请队列仅可以被第二CPU使用，即只有第二CPU可以从该申请队列中获取自身需要的内存，第二系统中的其他CPU不可以从该申请队列中获取需要的内存。相应的，队列维护CPU在建立申请队列后，将该申请队列的队列标识仅返回给第二CPU，第二CPU可以根据申请队列的队列标识找到与自身具有对应关系的申请队列，在获取内存时，从该对应的申请队列中获取自身需要的内存。

若第二CPU的内存需求中携带有多消费者的申请队列类型标识，则表明第二系统中运行的其它CPU可以和该第二CPU共用同一申请队列，因此，队列维护CPU建立与该第二CPU和其它CPU具有对应关系的申请队列，会向第二CPU和其它CPU返回该申请队列的队列标识，以便第二CPU和其它CPU根据该队列标识从该申请队列中获取内存。

具体的，与多个CPU均具有对应关系的申请队列可以被这多个CPU共用，当与某个申请队列具有对应关系的多个CPU中的任一个CPU需要获取内存时，即可根据该申请队列的队列标识，确定出与自身具有对应关系的申请队列，进而从该申请队列中获取自身所需的内存。

需要说明的是，由于该共用的申请队列为多核共用资源，所以涉及到加锁问题，具体的，当第二CPU从申请队列获取自身所需的内存时，需要对该申请队列进行加锁处理，以防止在此过程中，因其它与该申请队列具有对应关系的CPU也需要从该申请队列中获取自身所需的内存，而影响第二CPU的内存获取，待第二CPU从申请队列中获取自身所需的内存结束后，解除对申请队列的加锁处理，其它CPU可以从该申请队列获取自身需要的内存。

需要说明的是，本实施例中的申请队列均由队列维护CPU建立，且本申请不需要根据参数类型的不同建立对应于不同参数类型的申请队列，即使第二系统的CPU需要获取不同参数类型的内存，也均可从与该CPU具有对应关系的申请队列中获取，该CPU可以从该申请队列中获取到对应于各种需要的参数类型的内存。

由此可见，在建立申请队列时，无需根据参数类型的不同，为一个CPU建立分别与各个参数类型对应的各个申请队列，即本申请提供的技术方案对于一个CPU，仅需要为该CPU建立一个申请队列，该CPU可以通过该申请队列获取对应于各参数类型的内存，大大减少了申请队列的数量。进一步的，本申请提供的技术方案，对于同一系统内的多个CPU，也可以使用同一个申请队列申请对应于各个参数类型的内存，进一步减少了申请队列的数量。

此外，第二系统中的第二CPU还存在需要释放的内存，为了实现第二CPU的内存释放功能，本申请进一步提供了释放内存的方法。

实施例三

参见图4，为本实施例提供的一种释放内存的方法的流程图，该方法仍应用于多核异构平台，该多核异构平台包括异构的第一系统和第二系统，第一系统运行有队列维护CPU和至少一个第一CPU，第二系统运行有至少一个第二CPU，第一CPU和第二CPU之间存在信息交互，在上述实施例一的基础上，所述方法还可以包括：

S401：队列维护CPU轮询从预先建立的释放队列中读取内存。

S402：队列维护CPU将内存进行释放；其中，内存由所述第二CPU加入所述释放队列。

当第二CPU需要释放内存时，将自身需要释放的内存加入预先建立的释放队列中，队列维护CPU从该预先建立的释放队列中读取内存，将读取的内存释放至内存池中，这部分内存还可以重新被申请利用，为第二CPU提供所需的内存。

本实施例提供的多核异构平台下释放内存的方法，由队列维护CPU单独轮询释放队列，读取释放队列中待释放的内存，将其释放。在上述释放内存的过程中，释放队列的轮询及释放队列中内存的释放均由队列维护CPU单独执行，该异构平台中的其他CPU无需执行轮询释放队列以及释放其中的内存的操作，大大减少了对多核异构平台中其他CPU性能的损耗。

在上述释放内存的过程中，队列维护CPU从释放队列中读取待释放的内存，其中，用于存储待释放的内存的释放队列也是由队列维护CPU建立的，下面结合附图详细介绍释放队列的建立方法。

参见图5，为本实施例提供的一种释放队列的建立方法流程图，该释放队列建立的方法应用于多核异构平台，该多核异构平台包括异构的第一系统和第二系统，第一系统运行有队列维护CPU和第一CPU，第二系统运行有第二CPU，第一CPU和第二CPU之间存在信息交互，该方法包括：

S501：队列维护CPU建立对应于第二CPU的释放队列。

S502：队列维护CPU向第二CPU返回释放队列的队列标识；其中，释放队列的队列标识用于确定释放队列。

队列维护CPU为该第二CPU建立与之对应的释放队列，并向该第二CPU返回该释放队列的队列标识，因此，当该第二CPU需要释放内存时，第二CPU可以根据释放队列的队列标识找到与该第二CPU对应的释放队列，进而，将需要释放的内存加入至该释放队列中。

需要说明的是，本申请中的释放队列均由队列维护CPU建立，且本申请不需要根据参数类型的不同建立对应于不同参数类型的释放队列，即无论第二CPU需要释放对应于何种参数类型的内存，均可从与第二CPU具有对应关系的释放队列进行释放。

此外，队列维护CPU还可以建立被第二系统中多个第二CPU通用的释放队列，并由队列维护CPU向第二系统中多个第二CPU返回该释放队列的队列标识。

即第二系统中的多个第二CPU均可使用该通用的释放队列，当这多个第二CPU中任一第二CPU需要释放内存时，均可将需要释放的内存加入该通用的释放队列，队列维护CPU轮询该通用的释放队列，对该通用的释放队列中的内存进行释放，即可释放第二系统中多个第二CPU需要释放的内存。

需要说明的是，由于通用的释放队列为多核公用资源，所以涉及到加锁问题，具体的，若队列维护CPU所建立的释放队列为第二系统中多个第二CPU通用的释放队列，当第二系统中多个第二CPU中的任一个第二CPU利用该释放队列释放内存时，需要对该释放队列进行加锁处理，以防止在此过程中，第二系统中的其他CPU也需要利用该释放队列释放内存，而影响当前释放内存的CPU释放内存。当前释放内存的CPU将需要释放的内存释放结束后，解除加锁处理，此时第二系统中的其他CPU可以利用该释放队列释放内存。

为了避免出现多个CPU的资源竞争，本实施例提供的释放内存的方法，还可以为第二系统中的每个CPU均设置一个与之唯一对应的释放队列，当第二系统中各CPU需要释放内存时，相应地将需要释放的内存加入与之唯一对应的释放队列即可。由此，第二系统中的各CPU需要释放内存时，不需要对释放队列进行加锁处理，即可释放自身需要释放的内存，有效地避免了资源竞争。

由此可见，本实施例提供的技术方案，在建立释放队列时，无需根据参数类型的不同，为一个CPU建立与各个参数类型对应的各个释放队列，而是对于一个CPU，仅需要为该CPU建立一个释放队列，无需区分参数类型，该CPU将需要释放的内存填入该释放队列中即可，大大减少了释放队列的数量。进一步的，本申请提供的技术方案，还可以对于第二系统内的多个第二CPU，仅建立一个通用释放队列，即第二系统内的多个第二CPU均可将需要释放的内存填入该通用释放队列，进一步减少了释放队列的数量，进而减少了维护队列需要的成本。

为了便于理解本申请提供的技术方案，下面结合图6，将上述实施例提供的申请队列的建立方法、释放队列的建立方法、利用申请队列申请内存的方法以及利用释放队列释放内存的方法综合起来，对多核异构平台中两个处于不同系统的CPU之间进行信息交互的过程进行说明：

该过程应用于多核异构平台，多核异构平台包括异构的第一系统和第二系统，第一系统运行有队列维护CPU和第一CPU，第二系统运行有第二CPU，第一CPU和所述第二CPU之间存在信息交互。该过程包括：

S601：队列维护CPU根据第二CPU的内存需求中携带的申请队列类型标识，建立与该第二CPU具有对应关系的申请队列，并向第二CPU返回该申请队列的队列标识。

S602：队列维护CPU建立对应于第二CPU的释放队列，并向第二CPU返回释放队列的队列标识。

队列维护CPU可以根据第二CPU的内存需求中携带的申请队列类型标识，建立与该第二CPU对应的申请队列；若第二CPU的内存需求中携带有单消费者的申请队列类型标识，则可建立与该第二CPU唯一对应的申请队列，若第二CPU的内存需求中携带有多消费者的申请队列类型标识，则可建立对应于该第二CPU的申请队列，该申请队列还可以与第二系统中其他CPU具有对应关系。

相应的，与第二CPU对应的申请队列建立完成后，队列维护CPU向该第二CPU发送该申请队列的队列标识，以便该第二CPU查找并使用该申请队列申请自身需要的内存。

队列维护CPU还需要建立与第二CPU对应的释放队列，并向该第二CPU返回该释放队列的队列标识，以便该第二CPU根据该队列标识确定该释放队列，并向该释放队列中加入内存。此外，队列维护CPU还可以建立可供第二系统中所有CPU使用的通用释放队列，并在该通用释放队列建立完成后，向第二系统中所有CPU返回该通用释放队列的队列标识，以便第二系统中的任意CPU确定该通用释放队列，并向该通用释放队列中加入内存，以便队列维护CPU完成内存的释放。

需要说明的是，步骤601和步骤602为互相独立的两个步骤，执行顺序不分先后，可以先执行步骤601，后执行步骤602，也可以先执行步骤602，后执行步骤601，在此不做任何限定。

S603：队列维护CPU根据第二CPU的内存需求，从位于第一系统的内存池中申请内存，并将申请的内存加入预先建立的申请队列中。

队列维护CPU获取第二CPU的内存需求，从预先建立的位于第一系统的内存池中申请内存，并将该申请的内存对应地加入步骤301中建立的申请队列中，以便第二CPU能够根据队列标识，找到与之具有对应关系的申请队列，并从该申请队列中获取内存。

队列维护CPU轮询各个申请队列，以确定各个申请队列中的内存是否满足预设条件。

队列维护CPU在确定任一申请队列中的内存未满足所述预设条件时，向所述申请队列中添加内存。

申请队列中的内存所需要满足的预设条件可以为申请队列中的内存为满，队列维护CPU每隔一段时间就需要轮询一次申请队列，判断各个申请队列中存储的内存是否已满，若申请队列中存储的内存不满，则从内存池中获取内存添加至相应的申请队列中；若申请队列中存储的内存已满，则不必从内存池中获取内存添加至相应的申请队列中。

此外，申请队列中的内存所需要满足的预设条件还可以为申请队列中的内存不为空，队列维护CPU还可以每隔一段时间轮询一次申请队列，判断各申请队列中存储的内存是否不为空，若申请队列中存储的内存不为空，，则不必从内存池中获取内存，加入至相应的申请队列中。若申请队列中存储的内存为空，队列维护CPU则需要从内存池中获取内存，将获取的内存加入申请队列中。

S604：队列维护CPU从预先建立的释放队列中读取内存，并将所述内存进行释放。

第二CPU会将自身需要释放的内存，释放至与之具有对应关系的释放队列中。队列维护CPU每隔一段时间，轮询读取一次释放队列中的内存，并将读取到的释放队列中的内存释放至内存池中。

上述过程中，申请队列的建立和轮询、释放队列的建立和轮询均由队列维护CPU单独执行，异构平台中的其他CPU无需建立和轮询各个队列，大大减少了异构平台中其他CPU性能的损耗。此外，由队列维护CPU建立的申请队列和释放队列，均不需要根据参数类型的不同进行区分，即针对于同一CPU，申请各种参数类型对应的内存均可使用与该CPU对应的申请队列，释放各种参数类型对应的内存也均可使用与该CPU对应的释放队列，申请队列和释放队列的数量大大减少。并且，在一些情况下，多个CPU可以共用一个申请队列和一个释放队列，又进一步减少了异构平台中队列的数量，进而减少了维护队列所需要的成本。

此外，对于队列维护CPU读取释放队列中的内存，并将其进行释放来说，本申请实施例提供的方法，队列维护CPU在释放需要释放的内存时，可以不直接将这部分内存释放至内存池中。

队列维护CPU可以从预先建立的释放队列中读取内存，将这部分内存加入至申请队列中。其中，内存由第二CPU加入该释放队列。

即队列维护CPU不将从预先建立的释放队列中读取的内存，直接释放至内存池中，而是确定该释放队列对应的第二系统中的CPU，进而确定该第二系统中的CPU对应的申请队列，将这部分需要释放的内存加入至该申请队列中。

例如，队列维护CPU读取与第二CPU对应的释放队列中待释放的内存，并查找到该第二CPU对应的申请队列，队列维护CPU将从对应于第二CPU的释放队列中读取的内存，直接加入至该第二CPU对应的申请队列。

此外，队列维护CPU还可以将从释放队列中读取的内存，随机释放至任一申请队列中，以供第二系统中的任一CPU可以从申请队列中获取该内存，并复用该内存。

相比于队列维护CPU将从释放队列中读取的内存直接释放至内存池中，再从内存池中获取内存添加至申请队列中，上述过程减少了将内存释放至内存池中和从内存池中获取内存两个步骤，直接将待释放的内存加入至申请队列当中，实现内存的复用。

一种应用场景中，在第二CPU向第一CPU发送消息时，如果第二CPU至第一CPU之间消息通道已满，一般情况下，第二CPU需要将该消息直接丢弃，并对该消息所占的内存进行释放。而本申请实施例提供的方法，可以无需将发送失败的消息所占的内存添加至释放队列进行释放，而是利用变量指针对其进行存储，以便第二CPU后续需要使用内存时，优先使用该变量指针对应的内存，减少了将内存释放至内存池中和从内存池中获取内存两个步骤。

申请队列设置有对应的变量指针，该变量指针用于存储第二CPU向第一CPU发送失败的消息所占的内存，所述内存的优先级高于所述申请队列中的内存。

第二CPU向第一CPU发送消息时，若发现第二CPU至第一CPU的消息通道已满，本申请实施例提供的方法可以将对应于该第二CPU向第一CPU发送失败的消息的内存，存储至与申请队列对应的变量指针所指的地址处。

由于该变量指针指的地址处存储的内存的优先级高于申请队列中内存的优先级，因此，第二CPU再次申请内存时，会先判断该变量指针是否为空，若该变量指针不为空，则表示该变量指针所指的地址处存储有内存，则第二CPU获取该地址处存储的内存，并改变变量指针为空；若该变量指针为空，则表示该变量指针所指的地址处没有存储内存，则第一CPU可以从对应的申请队列获取内存。

本实施例提供的方法，在第二CPU向第一CPU发送消息时，如果第二CPU至第一CPU的消息通道已满，则可以将发送失败的消息所占的内存存储至与申请队列对应的变量指针所指的地址处，而无需将该发送失败的消息的内存加入释放队列中，因而，减少了将内存释放至内存池中和从内存池中获取内存两个步骤。

与上述方法实施例相对应的，本发明实施例还提供了一种多核异构平台下信息交互的内存申请装置，所述多核异构平台包括异构的第一系统和第二系统，所述第一系统运行有所述装置和至少一个第一CPU，所述第二系统运行有至少一个第二CPU。

参考图7，为本发明实施例提供的一种多核异构平台下信息交互的内存申请装置的结构示意图，所述装置包括：

申请模块701，用于根据内存需求申请内存；其中，所述内存需求来自与任一第一CPU存在信息交互的第二CPU；

第一加入模块702，用于将所述内存加入到预先建立的申请队列中，以便所述第二CPU从所述申请队列中获取所述内存。

参考图8，为本发明实施例提供的另一种多核异构平台下信息交互的内存申请装置的结构示意图，所述装置除了包括图7中的模块，还包括：

释放模块801，用于轮询从预先建立的释放队列中读取内存，并将所述内存进行释放；其中，所述内存由所述第二CPU加入所述释放队列。

具体的，所述内存需求中携带有申请队列类型标识；所述装置还包括：

第一建立模块，用于根据所述申请队列类型标识，建立与所述第二CPU具有对应关系的申请队列，并向所述第二CPU返回所述申请队列的队列标识；其中，所述申请队列的队列标识用于确定所述申请队列。

一种实施方式中，至少两个第二CPU与所述申请队列具有对应关系；所述装置还包括：

第一返回模块，用于向所述至少两个第二CPU返回所述申请队列的队列标识，以便所述至少两个第二CPU根据所述队列标识从所述申请队列中获取内存。

另一种实施方式中，每个第二CPU分别对应于一个申请队列。

具体的，所述装置还包括：

第二建立模块，用于建立对应于所述第二CPU的释放队列，并向所述第二CPU返回所述释放队列的队列标识；其中，所述释放队列的队列标识用于确定所述释放队列。

一种实施方式中，每个第二CPU分别对应于一个释放队列。

另一种实施方式中，所述释放队列为所述至少一个第二CPU通用的释放队列；所述装置还包括：

第二返回模块，用于向所述至少一个第二CPU返回所述释放队列的队列标识。

具体的，所述装置还包括：

第二加入模块，用于从预先建立的释放队列中读取内存，将所述内存加入至任一申请队列中；其中，所述内存由所述第二CPU加入所述释放队列。

一种实施方式中，所述申请队列设置有对应的变量指针，所述变量指针用于存储所述第二CPU向所述第一CPU发送失败的消息所占的内存，所述内存的优先级高于所述申请队列中的内存。

实际应用中，所述装置还包括：

轮询模块，用于轮询各个申请队列，以确定各个申请队列中的内存是否满足预设条件；

添加模块，用于在确定任一申请队列中的内存未满足所述预设条件时，向所述申请队列中添加内存。

本申请提供的多核异构平台下信息交互的内存申请装置中，多核异构平台包括异构的第一系统和第二系统，第一系统运行有队列维护CPU和至少一个第一CPU，第二系统运行有至少一个第二CPU。具体的，该装置接收来自与任一第一CPU存在信息交互的第二CPU的内存需求，根据该内存需求申请内存，并将内存加入到预先建立的申请队列中，以便该第二CPU从申请队列中获取该内存。本申请中由该内存申请装置单独为与任一第一CPU存在信息交互的各个第二CPU申请内存，其他CPU无需参与，大大减少了多核异构平台中其他CPU性能的损耗。

相应的，本发明实施例还提供一种多核异构平台下信息交互的内存申请设备，参见图9所示，可以包括：

处理器901、存储器902、输入装置903和输出装置904。多核异构平台下信息交互的内存申请设备中的处理器901的数量可以一个或多个，图9中以一个处理器为例。在本发明的一些实施例中，处理器901、存储器902、输入装置903和输出装置904可通过总线或其它方式连接，其中，图9中以通过总线连接为例。

存储器902可用于存储软件程序以及模块，处理器901通过运行存储在存储器902的软件程序以及模块，从而执行多核异构平台下信息交互的内存申请设备的各种功能应用以及数据处理。存储器902可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等。此外，存储器902可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。输入装置903可用于接收输入的数字或字符信息，以及产生与多核异构平台下信息交互的内存申请设备的用户设置以及功能控制有关的信号输入。

具体在本实施例中，处理器901会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器902中，并由处理器901来运行存储在存储器902中的应用程序，从而实现上述多核异构平台下信息交互的内存申请方法中的各种功能。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请实施例所提供的一种多核异构平台下信息交互方法、装置及设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。