在很多人看来，似乎嵌入式Linux可以为嵌入式开发人员做所有的事情。虽然嵌入式Linux可以适用于一些具有数兆内存和强大处理器的应用，但越来越多的用例表明，嵌入式Linux和类似操作系统的开销会对确定性和内存消耗产生负面影响。
蜂窝调制解调器、高性能视频处理和复杂的汽车控制器只是在小尺寸、低功耗多核平台的对称多处理(SMP)架构下运行的高度确定性应用的几个示例。此类系统需要底层操作系统的核心分配和任务调度支持，以满足硬实时要求，同时又不影响资源使用。
在资源受限的平台上，嵌入式Linux不是SMP的可行选择，支持SMP的实时操作系统(RTOS) 也寥寥无几。因此，开发人员必须创建自己的方法来跨多个内核调度和管理任务。
随着越来越多的嵌入式设备需要跨多个内核部署确定性工作负载，RTOS层的动态负载均衡需求只会不断增长。
SMP和非对称多处理(AMP)是两个或多个处理器协同工作来调度和运行工作负载的架构模式。SMP系统的内核完全相同，可以运行分配给它们的任何任务，而AMP系统通常依赖于单个主内核，根据可用性和优先级来调度和分配任务。在AMP系统中，核心本身不需要是相同的类型或架构(例如，MPU可以与GPU协同工作)，并且任务通常是针对内核类型的。
当开发人员可以依赖于一个稳定且可预测的环境时，AMP模式效果最佳，因为操作系统可以有效地分配工作负载，而不会产生大量开销。相比之下，对于在事件不断变化的环境中运行的应用，需要在不同内核之间动态转移工作负载时，SMP模式通常效果最佳。例如，许多手机都使用SMP，像是在Arm®Cortex®-A53平台上实现蜂窝调制解调器功能的手机。
为了有效地跨多个内核分配应用线程，嵌入式软件开发人员使用了动态负载均衡技术。其主要目标是确保应用在运行时在内核之间均匀分配计算工作负载，并保证优先级最高的线程不会被优先级较低的线程抢占。
动态负载均衡中的“动态”是指运行时对线程调度进行持续评估，使应用能够适应不断变化的任务需求和系统条件。动态负载均衡对于以下方面至关重要：
嵌入式Linux自带负载均衡机制，但也有缺点：操作系统会产生高昂的开销，这可能会严重影响确定性。由于大多数硬实时RTOS不支持SMP架构上的负载均衡，因此开发人员通常会自行构建支持机制。这项工作本身也存在挑战：
像是PX5 RTOS这类专为基于多核MPU的应用而设计的RTOS可以提供内置负载均衡功能，能够满足硬实时确定性的要求，且开销远远低于嵌入式Linux和其他操作系统。PX5 RTOS采用原生POSIX pthreads API，运行所需的内存不到10KB，具有极高的可移植性和资源效率，使开发人员无需构建自己的负载均衡器。
这种RTOS原生负载均衡器的运行方式与许多流行的负载均衡技术相同：
这种方法使用与嵌入式Linux相同的处理器关联API，使开发人员可以轻松地将线程分配给特定内核并依赖RTOS来强制执行此类分配。与大多数RTOS一样，开发人员必须确保共享资源的恰当管理，以避免出现争用问题。
在典型的单核、基于优先级的抢占式调度环境中，开发人员一次只能依赖一个运行的线程。在SMP环境中，由于多个线程可以在任意数量的内核上并行运行，因此这一条件无法保证。为了避免这种行为对系统的潜在负面影响，即要求在给定时间内只运行优先级最高的线程，PX5 RTOS让开发人员能够配置调度，仅允许相同优先级的线程在所有内核上并行运行。这种方法强制执行更严格程度的并行，使开发人员对其系统的可预测性更有信心。
开发人员要在小尺寸、低功耗的多核平台上实现极高的实时性能和响应速度，就必须实现动态负载均衡。像是PX5 RTOS负载均衡功能这样的机制支持将就绪的应用线程与可用内核动态配对，所有这些都在一个超小(小于10KB)、超便携(具有完全兼容的pthreads API)，并且经过严格测试(每个版本的C语句和分支决策覆盖率都达到100%）的封装内实现的。
RTOS原生负载均衡使开发人员能够专注于应用逻辑和测试，而不必自己构建在多个处理器之间分配工作负载的方法。
(原文刊登于EDN姊妹网站Embedded，参考链接：How to achieve real-time dynamic load balancing with an RTOS，由Ricardo Xie编译。)
最前沿的电子设计资讯
