时间戳

首页 > 解决方案 > 通过 prio-preempt 在 Linux RT LTS4.4 上测试优先级抢占

linux-kernel - 通过 prio-preempt 在 Linux RT LTS4.4 上测试优先级抢占

问题描述

我的系统使用 Arm cortexa7@1GHz 和来自 CIP 社区的实时补丁集 Linux 4.4.138-rt19：v4.4.138-cip25-rt19

我已经运行了一个 prio-preempt.c 来验证我系统上的优先级抢占。但是我遇到了一个问题：系统可能只运行了少于 27 个创建线程的线程。

关于理论方面，ltp app prio-preempt 创建了 27 个具有不同优先级的 worker_threads，N 个 busy_threads（N：取决于 CPU 的数量，在我的情况下 N = 2）具有高优先级，以及 master_thread（最高优先级）。

将应用程序部署到板上时，threads_running始终低于 27，而create_fifo_thread(worker_thread,i,...)成功创建了 27 个 worker_thread(s)。我在 cortexa15@1.5GHz 上运行了上面相同的程序，问题没有发生。

为了进一步了解，我认为问题可能来自 Linux RT 调度程序在bmutex锁被释放后无法唤醒睡眠线程。

有人对我有同样的问题吗？请分享你的想法。

标签： linux-kernellinux-rt

解决方案

基本上，在 Linux FULL Preemptive RT 系统中，较高优先级的线程总是抢占较低优先级的线程来控制 CPU。就我而言，问题实际上发生在速度更高的处理器上，我在双 cortexa15@1.5 GHz 或四核 cortexa15@1.4GHz 上进行了测试。但是，失败率要低得多。

因为问题是随机发生的，所以在发生故障的情况下，所有 CPU 都会同时执行优先级较高的线程，而忘记优先级较低的线程。

因此，我分配了某个 CPU 来执行特定线程（高优先级）。

#define CPU_0 0x01 /* Bind CPU 0 */
#define CPU_1 0x02 /* Bind CPU 1 */
#define CPU_2 0x04 /* Bind CPU 2 */
#define CPU_3 0x08 /* Bind CPU 3 */
...
{
    unsigned long cpuset = CPU_0;

    if (pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset) < 0) {
       printf("failed to pthread_setaffinity_np\n");
    }
}

并让出其他 CPU 来完成其他工作（低优先级）。我的系统不再挂起，可能会运行所有 27 个 worker_thread（低优先级线程）

推荐阅读