Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

周三技术交流纪要：StarryOS 在 K3 上的驱动与 AI 运行时适配

一、本次交流核心总结

我的工作以 SpacemiT K3 COM260 Kit 为硬件平台、StarryOS 为软件平台，目标是将 K3 板载 AI 算力纳入 StarryOS 的内核资源管理与调度体系。在此基础上，进一步提高 AI 任务分配和调度的灵活性，并为上层应用提供更统一、易用的 AI 算力调用方式。

当前工作已经从 QEMU 上的架构原型推进到 K3 COM260 Kit 真板验证。StarryOS 已可以通过 UFS rootfs 启动到 shell，并具备串口调试、基础中断、DMA/cache 一致性处理、RISC-V V 扩展上下文保存恢复等必要条件。

AI 运行时方面，已经打通“用户态 Runtime → UAPI → /dev/k3_airunner(目前是以ioctl操作k3_airunner来提交任务的实验性方式与starryos内核的调度器进行交互) → 内核 Scheduler → Backend → Completion”的最小闭环，CPU fallback MatMul、DAG 拓扑执行、共享 channel 和 A100 IME int8 MatMul 探针均已通过正确性验证。

完整 ggml/llama.cpp 模型尚未经由我自己的 Runtime 正确跑通,原因因为ggml的某些计算节点的实现有问题,具体点还未定位；K3 官方 Runtime 中与 spacemit-k3 Backend、Task 和 Scheduler 直接相关的实现细节也不足以支持 StarryOS 完整复用。

二、StarryOS 在 K3 上的驱动适配进展

模块当前状态已完成的验证尚存问题
K3 真板启动已打通StarryOS 可通过 UFS rootfs 启动到 shell暂无核心阻塞
UFS 驱动可用完成 UFSHCI/UIC/MPHY/UTP 主要链路的迁移和真板启动暂无核心阻塞
串口与调试通路已可用可用于启动、UFS、USB、AI runner、V/IME 调试暂无核心阻塞
APLIC/平台中断已接入已接入 StarryOS 的 K3 平台中断框架暂无核心阻塞
DMA/cache 基础能力已补齐基本机制使用 Zicbom 完成流式 DMA buffer 的 clean/invalidate；使用 Svpbmt 处理 USB ring/context 等高频共享结构暂无核心阻塞
USB/DWC3枚举链路已打通完成 K3 DWC3 平台兼容层；修复 ring/context 一致性后，crabusb 可继续枚举和传输流程实际设备的长时间传输、异常恢复及小车控制尚未充分验证
GMAC 网卡可用可以有效的进行网络通信暂无核心阻塞
SDMMC/SD 卡开发中无尚未完成
RISC-V V 扩展上下文已通过基础验证完成 32 个向量寄存器组及相关 CSR 的保存恢复；QEMU 和 K3 真板的同线程、跨线程、新线程隔离测试均通过X100 与 A100 的 VLEN 分别为 256 和 1024，活跃向量上下文目前不能随意跨类型迁移
AI 线程控制开发测试版/proc/set_ai_thread 可将当前线程标记为 AI 线程并调度到 AI 核心集合只能设置当前线程；取消 AI 标记后的跨 VLEN 返迁需要明确 safe point 和状态约束

三、AI 运行时适配进展

1. 已经打通的最小闭环

当前 AI 通路由以下模块组成：

     AI 应用
        ↓
onnx runtime ep/ggml
        ↓
k3_aiRuntime：tensor、graph、channel、submit/completion
        ↓
k3_aiUabi：内核与用户态共用 ABI
        ↓
/dev/k3_airunner：共享内存校验、保活和任务通道
        ↓
k3_aiScheduler：DAG 解析、ready queue、worker
        ↓
k3_kernel_backend：CPU / X100 / A100 路径分发
        ↓
completion token 返回用户态

已经完成的包括：

  • /dev/k3_airunner 的 BUILD_CHANNEL 能校验并保活用户态 MAP_SHARED 区域，用户态表层句柄释放后共享区仍然有效。
  • k3_aiScheduler 能把 (a || b) -> d 这类 DAG 解析为满足依赖约束的稳定拓扑序，当前由 worker 按 FIFO 执行。
  • CPU fallback MatMul 已打通 UAPI、Runtime、Driver、Scheduler、Backend 和 Completion 数据链路。
  • llama.cpp 的 RVV 与非 RVV 版本均能在 StarryOS K3 真板上运行 TinyStories 类小模型。

2. Backend 与模型接入进展

k3_kernel_backend 已经补充了 MatMul、Conv2D、二元/一元 elementwise、Softmax、RMSNorm、RoPE、SwiGLU、MaxPool、ReduceMax、TopK 和多种 tensor transform 等算子，并对部分路径实现 RVV 加速。量化方面已覆盖 I8/U8 及 ggml Q8_0、Q3_K、IQ4_NL 的部分路径。

  • 当前只覆盖 F32 MatMul 桥接的核心路径。
  • 输入和输出仍需要复制，还不是零拷贝高性能方案。
  • 完整 ggml backend 接入 TinyStories 模型时的输出与预期不一致，尚未定位是节点遗漏、shape/stride/layout、量化语义、KV cache 还是其他推理环节的问题。

3. 官方 Runtime 行为调研

为了避免在不清楚官方 Scheduler 能力时重复造轮子，已在 K3 Ubuntu 上使用官方 ONNX Runtime + SpaceMIT Execution Provider 和量化 YOLOv8n 进行 E0-E3 黑盒实验。

当前 E0/E1 结果显示：

  • E0 无干扰时，100 次推理平均延迟约为 52.68 ms，吞吐约为 18.98 inference/s。
  • E1 中把 Runtime 外部负载逐核移动到 CPU8-15 后，推理活跃核和性能会随外部负载位置变化。其中一轮外部负载位于 CPU8 时，平均延迟约为 107.41 ms，吞吐降到约 9.31 inference/s。
  • 这可以证明官方 Scheduler 至少会对 Runtime 外的硬件负载产生响应，但还不能说明它已经具备 workload-aware 或 PMU-aware 的调度能力。

PMU 方面已整理出一部分 X100 raw event 映射，并验证 instructions、cycles、frontend/backend stall 等基本事件的采样链路。后续还需要校准 cache/memory 事件、采样周期、multiplexing 误差和数据归属。

4. 调度器目前只是最小形态

当前 Scheduler 只是完成 DAG 拓扑排序和 FIFO worker 执行。以下能力还未具备：

  • 多 A100/X100 核心的ai任务更灵活的调度策略。
  • Rust async 调度和 completion waker。
  • backpressure、cancel、timeout、reset 和 error fallback。
  • buffer planner、一次性 graph 提交和长 graph 检查点。
  • 多进程竞争、公平性和长时间压力测试。
  • 结合队列长度、PMU/Trace、DMA backlog 和历史延迟的动态负载均衡。

四、当前 K3 AI 算力适配 StarryOS 的主要困难

1. 官方 AI Runtime 与 StarryOS 调度层之间尚缺少稳定的对接边界

SpineRuntime 已经公开 BackendHandle、Stream、Grid/Tile、Future、Barrier/Event、Core Coordinator 和 runtime_stats() 等编程模型。但是，与 K3 真实硬件紧密相关的 spacemit-k3 Backend、Task descriptor 及其生命周期、Core Coordinator 内部机制，以及 Scheduler 的选核与资源统计实现，目前仍不足以支持我们直接修改、编译并重新部署到 StarryOS。

因此，当前存在两条不完全重合的技术路线：一条是继续完善 StarryOS 上的自研 Runtime，另一条是获得官方 Scheduler 扩展点后，在官方 Runtime 的任务模型和调度策略上进行对接。如果不先明确两者边界，就可能在 Task、Stream、TCM/DMA 以及多进程资源协调等方面，重复实现官方 Runtime 已经具备的能力。

目前开发重心正逐步转向：在保留官方 Runtime 执行模型和既有调度策略的基础上，将 K3 AI 算力纳入 StarryOS 内核的统一资源管理与调度。这样可以同时结合官方 Runtime 对 AI 任务的理解，以及 StarryOS 对系统负载、核心状态和任务优先级的全局视角，使 AI 算力的调度和分配更加灵活。

以 YOLOv5 为当前验证对象，具体落点是对 ONNX Runtime 的 K3 Execution Provider（K3 后端）进行必要的代码适配：将模型推理任务通过明确的接口交给 StarryOS 调度层，再由内核结合当前资源状态完成 AI 核心的分配和任务放置。这一路径的重点是将官方 Runtime 与 StarryOS 调度机制结合起来，而不是重新实现整套模型推理流水线。

2. PMU 数据丰富度影响调度策略

目前公开的 PMU 映射仅覆盖部分 X100 性能事件，一些 DTS 允许使用的 raw selector 仍没有公开语义；A100 侧可供 Runtime 稳定采集的资源事件范围也不明确。A100 cluster 中配有专用的 TCM（Tightly Coupled Memory，紧耦合存储器）。如果 A100 PMU 能够提供足够丰富且语义明确的性能事件，尤其是能够反映 TCM 访问、冲突、带宽或等待压力的事件，调度器就有机会识别“计算单元空闲但片上存储受限”这类状态。相比只依赖队列长度或核心 busy/idle，这类信息可以为任务选核、负载均衡和干扰规避提供更细粒度的依据。

另一方面，PMU counter 数量有限，事件多路复用、采样窗口、上下文切换以及样本数据能否准确归属到具体任务或核心，都会影响统计结果的准确性。因此，现阶段应先通过微基准完成事件语义、采样周期、开销和稳定性校准，不宜仅根据单次 PMU 差值直接决定任务放置。