2. 系统架构设计:AMP、SMP、BMP 对比与选择

好,咱们进入正题。系统架构怎么选?

说白了,就是决定「几个核怎么干活」的问题。你想想看,一个芯片上可能有好几个 CPU 核心,它们之间怎么配合?是各干各的,还是一起干,还是有个边界?

这就引出了三种主流架构:AMP(非对称多处理)SMP(对称多处理)BMP(边界多处理)。我这些年做过的项目,几乎都绕不开这三个词。

2.1 AMP 架构:各司其职,互不干扰

AMP 的全称是 Asymmetric Multi-Processing。翻译过来就是「非对称多处理」。

什么意思呢?就是每个核心跑不同的操作系统,干不同的事。比如核心0跑 Linux,负责网络、显示这些复杂任务;核心1跑 RTOS,负责电机控制、传感器采集这些实时任务。

它们之间没有共享的操作系统内核,各自独立。通信嘛,一般通过共享内存或者硬件 mailbox 来做。

我个人的经验:AMP 最适合「隔离要求极高」的场景。比如工业控制器,一边要跑人机界面(Linux),一边要跑伺服驱动(RTOS)。两边崩了谁都不能影响谁。

优点很明显:

  • 隔离性好:一个系统挂了,另一个还能撑住
  • 实时性有保障:RTOS 那边不会被 Linux 的调度拖累
  • 开发灵活:两边可以用不同的工具链、不同的语言

缺点也扎心:

  • 资源浪费:Linux 那边闲着的时候,RTOS 这边忙死,没法借力
  • 通信开销大:跨核通信要走共享内存,延迟比内部调用高不少
  • 调试麻烦:两边各有一套调试工具,出了问题得两头查
避坑指南:我曾经在一个项目中,AMP 两边共享内存没做互斥保护,结果 RTOS 写数据时 Linux 正好在读,读到了一半新一半旧的数据。嗯,从那以后我每次做 AMP 通信,都会加一个简单的信号量或者 ring buffer。

2.2 SMP 架构:一视同仁,共同进退

SMP 就是 Symmetric Multi-Processing。对称多处理。

这个大家应该比较熟悉了。多个核心跑同一个操作系统,共享内存、共享外设、共享调度器。Linux 的 SMP 支持已经非常成熟了。

说白了,就是所有核心平等,谁有空谁干活。任务由操作系统统一调度。

优点:

  • 负载均衡好:一个核忙不过来,自动把任务分给其他核
  • 开发简单:写代码时不用操心哪个核跑什么,操作系统帮你搞定
  • 资源利用率高:不会出现一个核闲死、另一个核累死的情况

缺点:

  • 实时性难保证:Linux 的调度器不是硬实时的,高负载下任务可能被延迟
  • 隔离性差:一个核上的驱动崩了,可能把整个系统带翻
  • 锁竞争严重:多个核抢同一把锁,性能会急剧下降
注意:如果你要做硬实时控制,比如 1ms 以内的响应,纯 SMP 的 Linux 基本搞不定。我试过在 SMP Linux 上跑电机控制,结果调度抖动直接让电机抖成筛子。后来还是切到了 AMP 方案。

2.3 BMP 架构:折中之道,边界清晰

BMP 是 Bound Multi-Processing。边界多处理。

这个架构知道的人不多,但我个人觉得它是个「甜点」。BMP 本质上还是 SMP,但你可以给某些核心绑定特定的任务。

比如,你可以把核心0和核心1留给 Linux 用,核心2和核心3专门跑 RTOS。两边还是共享内存,但调度上做了隔离。

怎么实现? 在 Linux 里用 cpuset 或者 taskset 把进程绑定到指定核心上。RTOS 那边也类似,只使用分配给它的核心。

# 示例:把 Linux 的进程绑定到核心0和核心1
# 在启动脚本里设置
echo "0-1" > /sys/fs/cgroup/cpuset/linux_cpus/cpuset.cpus
echo "2-3" > /sys/fs/cgroup/cpuset/rtos_cpus/cpuset.cpus

# 然后启动 Linux 进程时指定 cgroup
cgexec -g cpuset:linux_cpus ./my_linux_app

优点:

  • 兼顾实时性和通用性:RTOS 那边可以做到硬实时,Linux 这边还能跑复杂应用
  • 资源利用率比 AMP 高:空闲时两边可以互相借力(但需要小心设计)
  • 开发相对简单:两边还是用同一套硬件抽象层

缺点:

  • 边界管理复杂:核心分配一旦定下来,改起来很麻烦
  • 调试依然有挑战:跨系统的通信问题还是存在
  • 对硬件有要求:需要硬件支持核心隔离和中断分发
我的建议:如果你既想要 Linux 的生态,又想要 RTOS 的实时性,BMP 是个不错的起点。我最近一个边缘计算网关项目就是这么干的——核心0-1跑 Linux 做网络协议栈,核心2-3跑 FreeRTOS 做数据采集,效果出奇地好。

2.4 三张表说清楚怎么选

好了,三种架构都讲完了。怎么选?我整理了一张对比表,你直接拿去用。

维度 AMP SMP BMP
实时性 高(RTOS 独立运行) 低(受 Linux 调度影响) 中高(绑定核心可保证)
隔离性 强(系统级隔离) 弱(共享内核) 中(核心级隔离)
资源利用率 低(各管各的) 高(动态负载均衡) 中(静态分配)
开发复杂度 高(两套工具链) 低(一套工具链) 中(需要配置绑定)
典型场景 工业控制、汽车电子 服务器、桌面系统 边缘计算、网关设备

再给一个决策流程,帮你快速判断:

  1. 需要硬实时(响应 < 1ms)? → 选 AMP 或 BMP
  2. 需要跑复杂应用(数据库、Web 服务)? → 选 SMP 或 BMP
  3. 两个都要? → BMP 是首选
  4. 开发团队小,想快速出活? → SMP 最省事
  5. 安全关键系统(不能死机)? → AMP 最稳妥
最后说一句:没有完美的架构,只有合适的架构。我见过有人用 SMP 硬扛实时任务,结果加了一堆优先级反转补丁,代码比业务逻辑还复杂。也见过有人用 AMP 做简单数据转发,结果通信开销比任务本身还大。选型之前,先想清楚你的核心诉求是什么。

嗯,这一章就到这儿。下一章咱们聊聊具体的硬件平台选型,比如怎么挑一颗合适的 SoC 来跑这套混合系统。