具有实时任务的多核Linux软锁定

当我搜索许多文档并且找不到任何提示时，我不确定这是否是Linux内核错误。我问这个问题来检查是否有人遇到过类似的问题以及如何解决这个问题。

Environment: 
Linux Kernel: 2.6.34.10 
CPU: MIPS 64 (total 8 cores)
application running in user space`

应用程序对响应时间有严格的要求，因此应用程序线程是在SCHED_FIFO中设置的，并且某些关键线程与专用CPU内核具有亲和力，在这种情况下，一切都很好。后来有人发现某些CPU内核有时会出现CPU峰值（例如，短峰值为60％-80％）。为了解决这个问题，通过在引导行中添加“ isolcpus = 1-6”，保留了用于Linux本机应用程序的CPU 0和CPU 7，并为我们的应用程序隔离了CPU 1-6，解决了CPU峰值问题，同时导致了以下问题。

运行一段时间和系统挂断后，以下消息将打印在控制台中，但不总是偶尔出现。（可能会在多个CPU内核中发生）

BUG: soft lockup - CPU#4 stuck for 61s! [swapper:0]
Modules linked in: hdml softdog cmt cmm pio clock linux_kernel_bde  linux_uk_proxy linux_bcm_core mpt2sas
Cpu 4
$ 0   : 0000000000000000 ffffffffc3600020 ffffffffc1000b00 c0000001006f0010
$ 4   : 0000000000000001 0000000000000001 000000005410f8e0 ffffffffbfff00fe
$ 8   : 000000000000001e ffffffffc15b3c80 0000000000000002 0d0d0d0d0d0d0d0d
$12   : 0000000000000000 000000004000f800 0000000000000000 c000000100768000
$16   : ffffffffc36108e0 0000000000000010 ffffffffc35f0000 0000000000000000
$20   : 0000000000000000 0000000000000000 0000000000000000 0000000000000000
$24   : 0000000000000007 ffffffffc103b3a0                                  
$28   : c0000001006f0000 c0000001006f3e38 0000000000000000 ffffffffc103d774
Hi    : 0000000000000000
Lo    : 003d0980b38a5000
epc   : ffffffffc1000b20 r4k_wait+0x20/0x40
    Not tainted
ra    : ffffffffc103d774 cpu_idle+0xbc/0xc8
Status: 5410f8e3    KX SX UX KERNEL EXL IE 
Cause : 40808000

查看回调跟踪，该线程始终在条件变量等待时处于挂起状态，伪等待/信号功能如下

int xxx_ipc_wait(int target)    
{
struct timespec to;

.... /* other code */
clock_gettime(CLOCK_MONOTONIC, &to);
timespec_add_ns(&to, 1000000);
pthread_mutex_lock(&ipc_queue_mutex[target]);
ret = pthread_cond_timedwait (&ipc_queue_cond[target], &ipc_queue_mutex[target], &to);
pthread_mutex_unlock(&ipc_queue_mutex[target]);

return ret;
}

void xxx_ipc_signal_atonce(int target)
{
... 
pthread_mutex_lock(&ipc_queue_mutex[target]);
pthread_cond_signal(&ipc_queue_cond[target]);
pthread_mutex_unlock(&ipc_queue_mutex[target]);
}

这些等待应该以任何方式唤醒，因为它是超时条件变量。甚至创建了一个专用的Linux线程来及时发出那些条件变量的信号，例如每5秒发出一次，仍然存在。

使用“ dmesg”检查了内核日志，但未找到任何有价值的日志。启用内核调试并检查内核日志/ proc / sched_debug时，有一些奇怪的信息，如下所示。

cpu#1   /* it is a normal CPU core */
  .nr_running                    : 1
  .load                          : 0
  .nr_switches                   : 1892378
  .nr_load_updates               : 167378
  .nr_uninterruptible            : 0
  .next_balance                  : 4295.060682
  .curr->pid                     : 235  /* it point to the runnable tasks */
            task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
----------------------------------------------------------------------------------------------------------
R         aaTask   235         0.000000       157    49                0               0         

cpu#4
  .nr_running                    : 1  /* okay */
  .load                          : 0
  .nr_switches                   : 2120455  /* this value changes from time to time */
  .nr_load_updates               : 185729
  .nr_uninterruptible            : 0
  .next_balance                  : 4295.076207
  .curr->pid                     : 0   /* why this is ZERO since it has runable task */
  .clock                         : 746624.000000
  .cpu_load[0]                   : 0
  .cpu_load[1]                   : 0
  .cpu_load[2]                   : 0
  .cpu_load[3]                   : 0
  .cpu_load[4]                   : 0
cfs_rq[4]:/
  .exec_clock                    : 0.000000
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 14.951424
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : -6833.777140
  .nr_running                    : 0
  .load                          : 0
  .nr_spread_over                : 0
  .shares                        : 0
 rt_rq[4]:/
  .rt_nr_running                 : 1
  .rt_throttled                  : 1
  .rt_time                       : 900.000000
  .rt_runtime                    : 897.915785

runnable tasks:
            task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
----------------------------------------------------------------------------------------------------------
       bbbb_appl   299         6.664495   1059441    49               0               0               0.000000               0.000000               0.000000 /

我不知道为什么Linux系统会这样工作，最后，我将任务优先级从SCHED_FIFO更改为SCHED_OTHER，并且在运行数月后未发生此问题。由于CPU内核是隔离的，因此SCHED_FIFO和SCHED_OTHER之间的系统行为相似，因此SCHED_OTHER也被更广泛地使用。