非隔离CPU与隔离CPU间IPC（含D-Bus等）通信可行性咨询

当你通过isolcpus或tuned-profiles-realtime将cpu2从Linux通用调度器中隔离后，进程A（非实时，cpu1）与进程B（实时，cpu2）之间的各类IPC机制完全可以正常工作——CPU隔离仅限制调度器的进程分配范围，不会影响内核提供的进程间通信基础设施。具体各类IPC的情况如下：

• Unix Socket：完全可行。Unix Socket由内核维护通信端点，无论进程运行在哪个CPU，只要能访问对应的socket文件或抽象命名空间，就能通过内核完成数据转发，CPU隔离状态对其无影响。
• 共享内存（shmem）：完全可行。共享内存是将同一块物理内存映射到多个进程的虚拟地址空间，内核负责内存的全局管理，进程在不同CPU上仅需访问这块共享内存即可完成通信，和CPU是否隔离无关。若实时进程B需要低延迟，可通过mlock锁定内存避免换页，但这属于性能优化，不影响通信本身的可行性。
• D-Bus（用户态IPC）：可行。D-Bus本地通信本质基于Unix Socket实现，只要D-Bus守护进程（通常运行在非隔离的cpu1）正常运行，进程A和B都能连接到守护进程或进行点对点通信。需要注意的是，若实时进程B对延迟敏感，D-Bus守护进程的调度延迟可能影响整体响应，但通信机制本身不会因CPU隔离失效。

额外说明：CPU隔离后，你需要手动将实时进程B绑定到cpu2（例如使用taskset -c 2 ./processB或chrt命令设置亲和性），但这只是进程的CPU亲和性配置，不会改变IPC的底层工作逻辑——内核的IPC子系统是全局生效的，与CPU核的调度隔离状态无关。

内容的提问来源于stack exchange，提问作者uohzxela