CN1945543A - 多核处理器的业务流处理方法及多核处理器 - Google Patents

Abstract

本发明涉及一种多核处理器的业务流处理方法及多核处理器。其中，方法包括：分流核将第一业务流分配给第一工作核；第一工作核根据响应等待周期向分流核回复响应信号；分流核在每个响应等待周期内判断是否收到来自于第一工作核的响应信号，当未收到该响应信号时，将第一业务流分配给第二工作核。多核处理器包括分流核及多个工作核，所述分流核包括，业务流分配单元和响应信号判断单元。所述工作核包括，业务流处理单元和响应信号回复单元。由于通过分流核对工作核的工作状态进行了监控，当某个工作核发生异常时，将业务流分配给其他正常运行的工作核，因此不会中断对业务流的处理，从而提高了多核处理器的可靠性。

Description

多核处理器的业务流处理方法及多核处理器

技术领域

本发明涉及一种多核处理器的业务流处理方法，尤其涉及一种通过分流核对工作核进行监控，以提高运行可靠性的方法及能够实现这种方法的多核处理器。

背景技术

多核处理器是指将多个通用CPU及一些功能部件集成封装到一块芯片中而形成的一个片上系统(System On Chip，简称，SOC)处理器。这个SOC中的通用CPU之间及CPU与芯片中的其他功能部件之间通过高速互联技术进行通信，与多CPU系统相比，大幅度提升了数据通信产品的软件处理能力，使系统性能得到进一步提升。

现有多核处理器按处理模式分为两种：一种是对称多处理(SymmetricalMulti-Processing，简称SMP)模式，另一种是非对称多处理模式

(Asymmetrical Multi-Processing，简称AMP)模式。其中，在SMP模式中，所有核都具有相同的功能，相当于多个单核设备在并发运行；而在AMP模式中，同时只有一个或部分核在操作系统中运行，主要承担协议的实现和对外接口等功能，而其他的核没有操作系统支持，只是完成数据转发等功能。SMP模式在实现上相对简单，但其对系统资源的占用是完全独立的，因此需要占用大量的系统资源，这对于大部分数据通信设备来说是很难满足的。因此，现有的多核处理器主要采用AMP模式实现业务应用。

现有技术的缺陷在于：利用多个核进行并行处理，虽然可以大大提高处理性能，但如果任何一个核出现了软件或硬件异常时都有可能导致整个业务系统的瘫痪，从而降低了系统的可靠性，反过来又限制了多核处理器的实际应用。现有的解决办法是使用从设备对主设备进行备份，当系统发生异常时，由从设备承担主要工作。这种方法实现起来简单，但需要购置大量的从设备用于备份，因此大大提高了组网成本，给客户带来了经济上的负担。除此之外，为了使主从设备的数据状态保持实时同步，主从设备之间要进行大量的数据交互，这些数据往往也要占用固定的业务端口，因此增加了系统开销，浪费了系统资源，对业务处理能力有一定的影响。并且，主从设备之间进行角色切换时还会有一定的延时，因此还会有可能造成业务处理的中断。

另外，在申请号为200610067781.1，名称为“具有活动和非活动执行核心的多核处理器”的专利公开文件中，为了解决多核处理器的可靠性问题，在单个集成电路中设置多个核心标识寄存器，一个标识寄存器对应于一个核心，用于标识该核心是否处于活动状态，将非活动的核心作为备用核心(参见公开文件第6页第4段)。该专利中，虽然不需要设置从设备进行备份，但仍然需要有备用核存在，因此降低了核心的利用率。

发明内容

本发明的目的是提供一种能够提高多核处理器可靠性的业务流处理方法，及能够实现上述方法的多核处理器。

为实现上述目的，本发明提供了一种多核处理器的业务流处理方法，包括：

分流核根据业务流分配原则将第一业务流分配给第一工作核；

第一工作核在对第一业务流的处理过程中，根据预先设定的响应等待周期向分流核回复响应信号；

分流核在每个响应等待周期内判断是否收到来自于第一工作核的响应信号，当未收到该响应信号时，将第一业务流分配给第二工作核。

为实现上述目的，本发明还提供了一种多核处理器，包括分流核及多个工作核，其中，

所述分流核包括，

业务流分配单元，用于根据业务流分配原则和/或来自于响应信号判断单元的判断结果，控制业务流在工作核间的分配；

响应信号判断单元，用于在每个响应等待周期内判断是否收到来自于工作核的响应信号，当判断出未收到响应信号时，将判断结果发送给业务流分配单元；

所述工作核包括，

业务流处理单元，用于对来自于分流核的业务流进行处理；

响应信号回复单元，用于在处理过程中，根据预先设定的响应等待周期向分流核回复响应信号。

因此基于本发明，由于通过分流核对工作核的工作状态进行了监控，当某个工作核发生异常时，将原本分配给该工作核的业务流分配给其他正常工作的工作核，因此不会中断对业务流的处理，从而提高了多核处理器的可靠性。由于本方法是基于现有多核处理器已有的内部资源，不需要在组网中增加其他备份设备，因此降低了生产成本；并且由于不需要另设备用核，也不需要占用业务端口，因此提高了系统资源的使用效率。另外，由于本实施例所述方法是在多核处理器内部实现的，内部总线的速度很高，因此能够保证重新分配业务流时不会产生较大时延，从而进一步减小了对业务流处理的影响。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

图1为本发明实施例1所述多核处理器的业务流处理方法流程图；

图2为本发明实施例2所述多核处理器的业务流处理方法流程图；

图3为本发明实施例3所述多核处理器的内部结构示意图；

图4为本发明实施例4所述多核处理器的内部结构示意图。

具体实施方式

实施例1

本实施例提供了一种通过由分流核对工作核的工作状态进行监控，以提高多核处理器可靠性的业务流处理方法，如图1所示，

步骤101，分流核根据业务流分配原则将第一业务流分配给第一工作核。其中，分流核是指在现有的多核并行处理业务中，设置在业务流入口处，用于将接收到的多个业务流在多个并行工作的工作核之间进行分配的核。业务流分配原则可以根据现有技术进行确定，如根据业务流中的五元组信息进行分配，或根据不同工作核的忙闲状态进行分配等，总之要使多个业务流尽量均匀的分配给工作核，以充分发挥所有工作核的工作效率。在本步骤中，第一业务流是指根据现有业务流分配原则分配给第一工作核的业务流。分流核与工作核相比，由于分流核的功能比较简单，出现异常的可能性非常小，因此对整个多核处理器的可靠性的影响可以忽略不计。

步骤102，第一工作核对第一业务流进行处理，在处理过程中，根据预先设定的响应等待周期向分流核回复响应信号。如果第一工作核能够正常工作，没有发生异常，则周期性地向分流核回复响应信号，以通知分流核，该第一工作核正处于正常工作状态。否则，如果第一工作核发生了异常，如软件运行异常或硬件故障异常等，该第一工作核便无法在预期时间内回复响应信号。另外，如果该第一业务流的业务数据信息，如中间计算结果、公式变量等，需要与其他工作核进行共享，还可以将这些业务数据信息保存在多核处理器的共享内存中。

步骤103，分流核在每个响应等待周期内判断是否收到来自于第一工作核的响应信号，当判断出未收到该响应信号时，将第一业务流分配给第二工作核，并且不再向发生了异常的第一工作核分配业务流。其中，第二工作核是指处于正常工作状态的区别于第一工作核的另一个工作核。如果分流核未收到响应信号，说明第一工作核在处理第一业务流时发生了异常，如果该第一业务流尚未处理完，则分流核将该第一业务流分配给第二工作核。如果第二工作核对第一业务流进行处理时，需要用到第一工作核处理第一业务流时产生的相关业务数据信息，则可以通过访问步骤102中所述的共享内存得到这些业务数据信息。

另外，需要说明的是，在某些情况下，由于软件处理延时或通信故障等原因，工作核虽然处于正常工作状态，但没能在响应等待周期内将响应信号及时地回复给分流核，或者回复的响应信号没能及时到达分流核，使得分流核误认为该工作核发生了异常，便中断向该工作核分配业务流，对业务流的处理会造成不必要的影响，也导致资源的浪费。为了尽可能减少分流核对工作核状态的误判，降低敏感度，可以预先设定一个判断次数，只有当分流核根据该判断次数均判断出未收到响应信号时，才将第一业务流分配给第二工作核，并且不再向第一工作核分配业务流。例如可以预先设定只有在连续三个响应等待周期内均判断出未收到响应信号时，才将第一业务流进行重新分配，并不再向该第一工作核分配其他业务流，尽可能地防止了对工作核正常工作的影响。

另外，还需要说明的是，多核处理器中还可以设置异常检测硬件单元，通过异常检测硬件单元对工作核进行监控，当检测到工作核发生异常时，向分流核发送中断信号；分流核收到该中断信号后，将第一业务流分配给第二工作核，从而保证处理器的可靠性。通过硬件实现对工作核的工作进行监控的优点是响应速度更快。与步骤101至103所述方法相结合，当响应等待周期较长时，能够更快地检测到工作核的异常，以防止在业务流执行过程中，由于等待时间过长而造成影响。

通过本实施例所述方法，由于通过分流核对工作核的工作状态进行了监控，当某个工作核发生异常时，将原本分配给该工作核的业务流分配给其他正常工作的工作核，因此不会中断对业务流的处理，从而提高了多核处理器的可靠性。由于本方法是基于现有多核处理器已有的内部资源，不需要在组网中增加其他备份设备，因此降低了生产成本；并且由于不需要另设备用核，也不需要占用业务端口，因此提高了系统资源的使用效率。另外，由于本实施例所述方法是在多核处理器内部实现的，内部总线的速度很高，因此能够保证重新分配业务流时不会产生较大时延，从而进一步减小了对业务流处理的影响。

实施例2

实施例1所述方法提高了整个多核处理器的可靠性，但发生了异常的工作核无法自动恢复运行，在一定程度上造成了资源的浪费，为了提高工作核的利用效率，本实施例提供了一种通过对发生了异常的工作核进行复位，使其恢复正常工作的业务流处理方法。如图2所示，

步骤101、102及103与实施例1所述步骤相同，此处不再赘述。

步骤104，分流核将第一业务流分配给第二工作核后，还向第一工作核发送复位指令信号，使第一工作核执行复位操作。具体地，分流核可以亲自向第一工作核发送复位指令信号，或者还可以通过设置在多核处理器中的异常检测硬件单元或未发生异常的正常工作核向第一工作核发送复位指令信号。其中，异常检测硬件单元是设置在多核处理器中的用于检测发生了异常的工作核的硬件单元，通过该硬件单元可以对工作核进行复位。另外，通过现有技术，也可以为工作核设计能够复位其他工作核的功能，例如在本步骤中，第一工作核发生了异常，可以通过其他正常工作核对该第一工作核进行复位。

步骤105，第一工作核完成复位操作后，向分流核发送复位确认信号。如果没能完成复位操作，当然也就无法发送该信号。

步骤106，分流核在预先设定的复位等待时间内判断是否收到来自于第一工作核的复位确认信号，当判断出收到复位确认信号时，执行步骤111，否则执行步骤112。

步骤111，分流核收到该复位确认信号后，继续根据业务流分配原则向第一工作核分配业务流。收到来自于第一工作核的复位确认信号，说明该工作核已经复位成功，恢复了正常工作状态，因此继续向其分配业务流，具体地，可以将尚未完成的第一业务流重新分配给第一工作核，或者将其他的新的业务流分配给第一工作核进行处理，总之按照现有的业务分配原则进行分配即可。

步骤112，向输出设备发送警告信号。工作核发生异常可能有软件原因或硬件原因，一般情况下，由软件原因引起的异常是可以通过复位解决的，而硬件发生损坏等硬件原因无法通过复位加以解决。因此，如果在复位等待时间内未收到来自于第一工作核的复位确认信号说明该工作核复位失败，且很可能发生了硬件损坏，因此发出警告信号以提醒用户进行相应处理。

此处需要指出的是，虽然由软件原因引起的异常可以通过复位解决，但不一定能够一次复位成功，或者复位需要很长时间。如果其实际复位时间超过了预先设定的复位等待时间，则分流核无法判断出该第一工作核能够通过复位修复，而是会错误地判断出其发生了硬件损坏。为了尽量减少误判的发生，当分流核在预先设定的复位等待时间内首次判断出未收到复位确认信号时，并不立即向输出设备发送警告信号，而是根据步骤104所述方法，再次向第一工作核发送复位指令信号，并重新在预先设定的复位等待时间内判断是否收到来自于第一工作核的复位确认信号，只有当分流核根据预先设定的判断次数，均判断出未收到复位确认信号时，才向输出设备发送警告信号，表明第一工作核由于硬件原因引起了异常，通知用户进行解决。

通过本实施例所述方法，停止了正常运行的第一工作核通过复位操作及时恢复了运行状态，因此提高了工作核的利用率。并且，即使发生了硬件损坏故障，也可以及时通知用户进行解决，不影响其他工作核的正常工作，保证了整个多核处理器的可靠性。

另外，需要指出的是，本实施例的步骤106中，也可以不预先设定复位等待时间，分流核如果收到来自于第一工作核的复位确认信号，则继续向其分配业务流；否则如果没有收到，也可以不做任何处理，而是由步骤104中所述的对第一工作核进行复位的异常检测硬件单元或其他正常工作核通知用户进行解决。

实施例3

本实施例提供了一种能够提高可靠性的多核处理器。如图3所示，为该多核处理器内部结构示意图。多核处理器10包括：分流核20，多个工作核，如工作核30、40等。其中，分流核20包括响应信号判断单元22和业务流分配单元21；每个工作核均包括响应信号回复单元和业务流处理单元。

在工作时，业务流分配单元21将接收到的业务流根据业务流分配原则给各个工作核。业务流分配原则可以根据现有技术进行确定，如根据业务流中的五元组信息进行分配，或根据不同工作核的忙闲状态进行分配等，总之要使多个业务流尽量均匀的分配给工作核，以充分发挥所有工作核的工作效率。假设业务流分配单元21收到的业务流中包括一个第一业务流，该第一业务流是指根据现有业务流分配原则分配给工作核30的业务流。分流核20与若干个工作核相比，由于分流核20的功能比较简单，出现异常的可能性非常小，因此对整个多核处理器10的可靠性的影响可以忽略不计。

工作核30的业务流处理单元32对来自于分流核20的第一业务流进行处理。在处理过程中，响应信号回复单元31以预先设定的响应等待周期向分流核20回复响应信号。如果工作核30能够正常工作，没有发生异常，则可以周期性地向分流核20回复响应信号，以通知分流核20，该工作核30正处于正常工作状态。否则，如果工作核30发生了异常，如软件运行异常或硬件故障异常等，该工作核30的响应信号回复单元31便不会在预期时间内回复响应信号。另外，如果该第一业务流的业务数据信息，如中间计算结果、公式变量等，需要与其他工作核进行共享，还可以将这些业务数据信息保存在多核处理器10的共享内存(图中未标出)中。

分流核20的响应信号判断单元22在每个响应等待周期内判断是否收到来自于工作核30的响应信号，当判断出未收到该响应信号时，将判断结果通过内部总线发送给业务流分配单元21，以通知业务流分配单元21工作核30发生了异常。业务分配单元21收到该判断结果后将第一业务流分配给工作核40，并且不再向发生了异常的工作核30分配业务流。其中，工作核40是指处于正常工作状态的区别于工作核30的另一个工作核。如果分流核20未收到响应信号，说明工作核30在处理第一业务流时发生了异常，如果该第一业务流尚未处理完，则分流核20将该第一业务流分配给工作核40。工作核40的业务流处理单元42对该第一业务流进行处理时，也要通过响应信号回复单元41向分流核20回复响应信号，使分流核20对工作核40的工作状态保持监控。如果工作核40对第一业务流进行处理时，需要用到工作核30处理第一业务流时产生的相关业务数据信息，则可以通过访问多核处理器10的共享内存得到这些业务数据信息。

另外，需要说明的是，在某些情况下，由于软件处理延时或通信故障等原因，工作核30虽然处于正常工作状态，但没能在响应等待周期内将响应信号及时地回复给分流核20，或者回复的响应信号没能及时到达分流核20，使得分流核20误认为该工作核30发生了异常，便中断向工作核30分配业务流，对业务流的处理会成不必要的影响，也导致资源的浪费。为了尽可能减少分流核20对工作核30状态的误判，降低敏感度，可以预先设定一个判断次数，只有当分流核20的响应信号判断单元22根据该判断次数，例如连续三次，均判断出未收到响应信号时，才将判断结果发送给业务流分配单元21，由业务流分配单元21将第一业务流分配给工作核40，并且不再向工作核30分配业务流。尽可能地防止对工作核30的正常工作的影响。

通过本实施例所述方法，由于分流核20可以对所有工作核的工作状态进行监控，当某个工作核发生异常时，将原本分配给该工作核的业务流分配给其他正常工作的工作核，因此不会中断对业务流的处理，从而提高了多核处理器的可靠性。由于本方法是基于现有多核处理器已有的内部资源，不需要在组网中增加其他备份设备，因此降低了生产成本；并且由于不需要另设备用核，也不需要占用业务端口，因此提高了系统资源的使用效率。另外，由于本实施例所述方法在多核处理器内部实现的，内部总线的速度很高，因此能够保证重新分配业务流时不会产生较大时延，从而进一步减小了对业务流处理的影响。并且，停止了正常运行的工作核通过复位操作可以及时恢复运行状态，因此提高了工作核的利用率。并且，即使发生了硬件损坏故障，也可以及时通知用户进行解决，不影响其他工作核的正常工作，保证了整个多核处理器的可靠性。

实施例4

本实施例提供了一种在实施例3的基础上能够使发生异常的工作核恢复运行的多核处理器。如图4所示，分流核20还包括复位指令单元23，每工作核还包括复位控制单元，如复位控制单元33、43等。

在工作时，响应信号判断单元22判断出未收到来自于工作核30的响应信号时，将判断结果通过内部总线发送给业务流分配单元21的同时，还将该判断结果发送给复位指令单元23，以通知复位指令单元23工作核30发生了异常。复位指令单元23收到该判断结果后，向工作核30发送复位指令信号。工作核30的复位控制单元33收到该复位指令信号后，对工作核30执行复位操作。复位成功后，复位控制单元33向分流核20发送复位确认信号。如果没能完成复位操作，当然也就无法发送该信号。分流核20的复位指令单元23在预先设定的复位等待时间内判断是否收到来自于工作核30的复位确认信号，当判断出收到复位确认信号时，将复位结果发送给业务流分配单元21，由业务流分配单元21继续根据业务流分配原则向工作核30分配业务流。否则向输出设备(图中未标出)发送警告信号。工作核发生异常可能有软件原因或硬件原因，一般情况下，由软件原因引起的异常是可以通过复位解决的，而硬件发生损坏等硬件原因无法通过复位加以解决。因此，如果复位指令单元23判断出工作核30复位失败，则很可能发生了硬件损坏，因此发出警告信号以提醒用户进行解决。

此处需要指出的是，虽然由软件原因引起的异常可以通过复位解决，但不一定能够一次复位成功，或者复位需要很长时间。如果其实际复位时间超过了预先设定的复位等待时间，则复位指令单元23无法判断出该工作核30能够通过复位修复，而是会错误地判断出其发生了硬件损坏。为了尽量减少误判的发生，当复位指令单元23在预先设定的复位等待时间内首次判断出未收到复位确认信号时，并不立即向输出设备发送警告信号，而是再次向工作核30发送复位指令信号，并重新在预先设定的复位等待时间内判断是否收到来自于工作核30的复位确认信号，只有当复位指令单元23根据预先设定的判断次数，如连续三次均判断出未收到复位确认信号时，才向输出设备发送警告信号，表明工作核30由于硬件原因引起了异常，通知用户进行解决。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围。

Claims (13)

1、一种多核处理器的业务流处理方法，包括：

分流核根据业务流分配原则将第一业务流分配给第一工作核；

第一工作核在对第一业务流的处理过程中，根据预先设定的响应等待周期向分流核回复响应信号；

分流核在每个响应等待周期内判断是否收到来自于第一工作核的响应信号，当未收到该响应信号时，将第一业务流分配给第二工作核。

2、根据权利要求1所述的多核处理器的业务流处理方法，其特征在于，所述将第一业务流分配给第二工作核之前还包括：分流核根据预先设定的判断次数判断出未收到响应信号。

3、根据权利要求2所述的多核处理器的业务流处理方法，其特征在于，还包括：分流核将第一业务流分配给第二工作核后，还向第一工作核发送复位指令信号，使第一工作核执行复位操作。

4、根据权利要求3所述的多核处理器的业务流处理方法，其特征在于，还包括：第一工作核完成复位操作后，向分流核发送复位确认信号。

5、根据权利要求4所述的多核处理器的业务流处理方法，其特征在于，还包括：分流核收到复位确认信号后，继续根据业务流分配原则向第一工作核分配业务流。

6、根据权利要求5所述的多核处理器的业务流处理方法，其特征在于，还包括：分流核在预先设定的复位等待时间内判断是否收到复位确认信号，当未收到复位确认信号时，向输出设备发送警告信号。

7、根据权利要求6所述的多核处理器的业务流处理方法，其特征在于，所述向输出设备发送警告信号之前还包括：当未收到复位确认信号时，再次向第一工作核发送复位指令信号，并根据预先设定的判断次数判断出未收到复位确认信号。

8、根据权利要求3-7任意项所述的多核处理器的业务流处理方法，其特征在于，还包括：通过多核处理器中的异常检测硬件单元对工作核进行监控，当检测到工作核发生异常时，向分流核发送中断信号；分流核收到该中断信号后，将第一业务流分配给第二工作核。

9、根据权利要求8所述的多核处理器的业务流处理方法，其特征在于，所述将分流核将第一业务流分配给第二工作核后还包括：通过异常检测硬件单元向第一工作核发送复位指令信号，使第一工作核执行复位操作。

10、根据权利要求3-7任意项所述的多核处理器的业务流处理方法，其特征在于，还包括：分流核将第一业务流分配给第二工作核后，通过未发生异常的正常工作核向第一工作核发送复位指令信号，使第一工作核执行复位操作。

11、根据权利要求2-7任意项所述的多核处理器的业务流处理方法，其特征在于，还包括：所述第一工作核对第一业务流进行处理还包括：将处理过程中的业务数据信息保存在多核处理器的共享内存中。

12、一种多核处理器，包括分流核及多个工作核，其特征在于：

所述分流核包括，

业务流分配单元，用于根据业务流分配原则和/或来自于响应信号判断单元的判断结果，控制业务流在工作核间的分配；

响应信号判断单元，用于在每个响应等待周期内判断是否收到来自于工作核的响应信号，当判断出未收到响应信号时，将判断结果发送给业务流分配单元；

所述工作核包括，

业务流处理单元，用于对来自于分流核的业务流进行处理；

响应信号回复单元，用于在处理过程中，根据预先设定的响应等待周期向分流核回复响应信号。

13、根据权利要求12所述的多核处理器，其特征在于：

所述分流核还包括复位指令单元，所述响应信号判断单元将判断结果发送给所述业务流分配单元的同时，还将判断结果发送给复位指令单元，复位指令单元用于根据该判断结果向未回复响应信号的工作核发送复位指令信号，并且当接收到复位确认信号时，将复位结果发送给所述业务流分配单元，否则向输出设备发送警告信号；

所述工作核还包括复位控制单元，用于根据所述复位指令信号对本工作核执行复位操作，复位成功后，向分流核发送复位确认信号。

Images