feat(starry): sysbench big.LITTLE benchmark and RK3588 board harness#1658
feat(starry): sysbench big.LITTLE benchmark and RK3588 board harness#1658JosephJoshua wants to merge 16 commits into
Conversation
b0e5018 to
e1a71ec
Compare
e1a71ec to
f9a195f
Compare
![mai-team-app[bot]](https://avatars.githubusercontent.com/u/34859362?s=60&v=4){kind=small}
There was a problem hiding this comment.
本 PR 新增了 sysbench 的 QEMU/OrangePi-5-Plus 工作流与采样脚本，并把 RK3588 的 SCMI/PMIC DVFS、AArch64 PMU 计数器和 axtask 忙碌 tick 接入 StarryOS，目标是取得可复现的 big.LITTLE 性能数据并改善板端扩频。它并非隔离改动：会改变 StarryOS 启动期任务、用户态 PMU 可见性、调度计数及真实 CPU 电源轨/时钟状态。
阻塞项见行内评论：动态 OPP 切换忽略 PMIC/SCMI 的失败结果，却仍提交软件 OPP 索引，失败后会把驱动状态与实际硬件状态永久脱节；下调时还可能在时钟变更失败后继续降低电压。请让转换返回可检查的结果，只有两端均确认成功后更新 IDX，并在失败时保留或读回/恢复已确认的 OPP。
验证：review_pr_helper.py test 与 prepare-review 通过；cargo fmt --all --check 通过；cargo clippy --manifest-path components/axcpu/Cargo.toml --all-features -- -D warnings、cargo test --manifest-path components/axcpu/Cargo.toml --all-features、cargo clippy --manifest-path drivers/ax-driver/Cargo.toml --features rk3588-cpufreq -- -D warnings、axbuild app-discovery 的 2 个测试、脚本语法/TOML/Python 检查及精确的 cargo xtask starry build --config apps/starry/sysbench-board/build-aarch64-unknown-none-softfloat.toml --arch aarch64 均通过。完整 ax-driver --all-features clippy 停在未改的 rockchip-npu needless_late_init；完整 host 测试还受既有架构内联汇编/extern-trait 链接约束，未将其归因于本 PR。
当前 HEAD 的 CI 共 59 个 check：29 成功、29 为条件跳过；OrangePi-5-Plus 自托管 check 成功。另有 aka-00-sg2002 板卡 check 被取消，未见本 PR 的失败结论。实际新 board app 需要物理板和部署后的 rootfs，本环境无法复跑；cargo xtask starry app list 已确认 sysbench-board 被发现，但仍需要一次能注入/观测 PMIC 与 SCMI 失败的确定性回归覆盖。
此前只有 Copilot 的配额提示，没有技术性 review thread；没有已有行内或 issue 评论需要解决。检索了 sysbench RK3588 与 cpufreq rockchip 的相关 PR，未发现可用的重叠实现。除上述硬件转换失败处理和其测试缺口外，未给出其他阻塞结论。
Powered by gpt-5.6-terra
| let hz = opp.ring_khz as u64 * 1_000; | ||
| if going_up { | ||
| cluster.set_voltage(opp.uv); | ||
| scmi::set_clock_rate(phandle, cluster.clock_id(), hz); |
There was a problem hiding this comment.
这里丢弃了 PMIC 写入和 SCMI 设频的失败结果，但 governor_poll 随后无条件把 IDX 更新为目标 OPP。因而一次 I2C/SPI read-back 不匹配或 SCMI 拒绝会使软件状态声称已经完成转换，后续轮询可能不再重试；尤其下调路径会在设频失败后仍继续降压。请让该函数返回可检查的转换结果：每一步读回确认，失败时不要更新 IDX，并保留或恢复/重新读取最后一个已确认的时钟与电压状态。
…write does not commit IDX
f9a195f to
07ef8bc
Compare
|
Rebased onto the fixed #1657 ( |
There was a problem hiding this comment.
本 PR 新增了 StarryOS 的 sysbench QEMU/OrangePi-5-Plus 场景、板端采样与比较脚本，并带入 RK3588 的 DVFS、PMU 计数和 axtask busy-tick 改动，用于验证 big.LITTLE 性能与扩频。它不是隔离的文档改动：会影响 StarryOS 启动任务、QEMU 测试结果判定、调度负载计数以及真实板端 CPU 电源轨/时钟。
有两个阻塞问题，详见行内评论：matrix 配置会把 threads 子测试失败伪装为 SYSBENCH_MATRIX_OK，而新加的 ax-driver 单元测试与当前 1,000,000 µV 的实现上限不一致并在当前 HEAD 失败。二者都会使回归覆盖失效或 CI 直接失败。
验证：review_pr_helper.py test、prepare-review、cargo fmt --check、cargo clippy --manifest-path drivers/ax-driver/Cargo.toml --features rk3588-cpufreq -- -D warnings、脚本语法/Python/TOML 解析均通过；cargo xtask starry app list 已确认 sysbench 与 sysbench-board 被发现。cargo test --manifest-path drivers/ax-driver/Cargo.toml --features rk3588-cpufreq --lib -- --nocapture 复现失败：20 通过、1 失败（envelope_is_down_only_675_to_800）。另外以失败的 sysbench threads stub 执行 line 22 的命令，进程仍退出 0 并打印 SYSBENCH_MATRIX_OK。已安装 QEMU；由于上述确定性阻塞项，未继续执行耗时的完整 QEMU/物理板流程。物理板 app 仍须在修复后验证其 guest 可见成功标记。
当前 HEAD 的 GitHub Actions run #29798977974 仍为 in_progress，尚不能作为通过证据；可见 checks 未报告完成的失败。此前针对 OPP 事务性的技术评论在本 HEAD 已合理解决：apply_opp 现在在失败时返回 false，IDX 仅在两个步骤成功后提交。Copilot 的旧评论只是额度提示；没有其他技术性 issue 评论。
重叠分析：#1657 是本 PR 明确叠加并已带入当前 HEAD 的 cpufreq 实现，属于依赖/部分重叠而非重复；#1656 的线程分布修复是互补关系。未发现另一份可替代本 PR app 工作流的开放实现。剩余阻塞项为两条行内问题。
Powered by gpt-5.6-terra
| uefi = false | ||
| to_bin = true | ||
| shell_prefix = "root@starry:" | ||
| shell_init_cmd = "sed -i -e 's|https://dl-cdn.alpinelinux.org/alpine|http://mirrors.tuna.tsinghua.edu.cn/alpine|g' -e 's|http://dl-cdn.alpinelinux.org/alpine|http://mirrors.tuna.tsinghua.edu.cn/alpine|g' -e 's|https://mirrors.cernet.edu.cn/alpine|http://mirrors.tuna.tsinghua.edu.cn/alpine|g' -e 's|http://mirrors.cernet.edu.cn/alpine|http://mirrors.tuna.tsinghua.edu.cn/alpine|g' /etc/apk/repositories; sed -i 's|^#* *\\(http.*/community.*\\)|\\1|' /etc/apk/repositories; grep -q '^[^#].*/community' /etc/apk/repositories || sed -n 's|/main$|/community|p' /etc/apk/repositories >> /etc/apk/repositories; (apk add sysbench || (apk update && apk add sysbench)) && for t in 1 2 4; do echo CPU_THREADS=$t; sysbench cpu --cpu-max-prime=20000 --threads=$t --time=3 run 2>&1 | grep -iE 'events per second|total number of events'; done; echo THREADS_T4; sysbench threads --threads=4 --time=3 run 2>&1 | grep -iE 'events per second|total number of events'; echo MUTEX_T4; sysbench mutex --threads=4 run 2>&1 | grep -iE 'total time|total number of events'; echo MEMORY_T4; sysbench memory --threads=4 --memory-total-size=512M run 2>&1 | grep -iE 'transferred|per second' && echo SYSBENCH_MATRIX_OK || printf 'SYSBENCH_%s\\n' HAS_FAILURES" |
There was a problem hiding this comment.
阻塞 / 测试失败传播： 这里的 && 只约束最后一个 memory 管道，前面的 threads 管道失败会被忽略，随后仍会执行 SYSBENCH_MATRIX_OK。我用一个 sysbench threads 返回 1 的 stub 执行整段命令，结果进程退出 0 且打印成功标记；外层 runner 因而会把 futex/threads 回归报告为成功。请让每个子测试的退出状态成为硬门（例如显式检查每条 sysbench 命令，或启用并依赖 pipefail 后立即失败），只在全部四类子测试都成功时打印成功标记。
| assert!(in_envelope(800_000)); | ||
| assert!(in_envelope(725_000)); | ||
| assert!(!in_envelope(674_999)); // below OPP floor | ||
| assert!(!in_envelope(800_001)); // above boot voltage |
There was a problem hiding this comment.
阻塞 / 新增单元测试失败： VDD_CEIL_UV 已是 1,000,000 µV，in_envelope 也以包含上界的范围实现，但本测试仍断言 800001 和 1,000,000 都应拒绝。当前 cargo test --manifest-path drivers/ax-driver/Cargo.toml --features rk3588-cpufreq --lib 因此在这里失败。请按当前安全包络更新测试名称和边界：1,000,000 应接受，1,000,001 应拒绝（并保留低端边界），使回归测试与实现的安全契约一致。
07ef8bc to
0e2e3e0
Compare
There was a problem hiding this comment.
审查结论：APPROVE ✅
本 PR 在 apps/starry/sysbench-board/ 和 apps/starry/sysbench/ 下新增 StarryOS 的 sysbench QEMU/OrangePi-5-Plus 场景、板端采样与对比脚本，并在 drivers/ax-driver 中加入 RK3588 CPU DVFS 驱动（SCMI 时钟 + PMIC 电压校准 + ondemand governor），在 components/axcpu 中启用 EL0 可读的 PMU 周期计数器，在 os/arceos/modules/axtask 中加入每个 CPU 的调度忙碌 tick 计数器供 governor 采样。
上一轮审查阻塞项的解决情况
上一轮审查（HEAD 07ef8bc）的两个阻塞问题均已解决：
- Matrix 配置掩盖子测试失败 → 最新版
qemu-aarch64-matrix.toml已改为fail=0/|| fail=1/[ $fail = 0 ]显式追踪失败，failure 时打印SYSBENCH_HAS_FAILURES，fail_regex能正确匹配。 - 单元测试
envelope_is_down_only_675_to_800失败 → 测试已更新为envelope_is_675k_to_1000k_inclusive，匹配已提升至 1.0V 的VDD_CEIL_UV。
同时，上一轮针对 OPP 事务性和 AArch64 内联汇编的条件编译修复已在此 HEAD 中就绪：apply_opp 在两个步骤（电压 + SCMI 时钟）都成功后才返回 true，IDX 仅在 apply_opp 成功时提交；mrs 汇编已用 #[cfg(target_arch = "aarch64")] 与 host stub 隔离。
验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
cargo clippy --features rk3588-cpufreq (ax-driver) |
✅ 通过 |
cargo clippy --all-features (axtask) |
✅ 通过 |
cargo clippy --all-features (axcpu) |
✅ 通过 |
cargo test --features rk3588-cpufreq --lib (ax-driver) |
✅ 21 通过，0 失败 |
| GitHub Actions CI | ✅ 29 成功，29 跳过（矩阵/path filter 预期），0 失败 |
| StarryOS OrangePi-5-Plus 自托管板卡 check | ✅ 成功 |
代码质量评估
- DVFS 驱动：
cpufreq.rs的 governor 逻辑清晰，per-core 打分（Linux schedutil/ondemand 同义）、快攻慢退（UP_THRESHOLD=80% 一步到顶，DOWN_THRESHOLD=30% 逐级衰减）、事务性 OPP 应用（先电压后频率升频，先频率后电压降频，失败不回写 IDX）都符合 Linux DVFS 设计模式。 - PMIC 驱动：
pmic_i2c.rs/pmic_spi.rs包含完整的寄存器级文档和板端实测数据，电压编码/解码单元测试覆盖边界条件。 - axtask 改动：
BUSY_TICKS使用Relaxed原子量，在 IRQ + preempt 关闭的 tick handler 中递增，开销极小，对调度路径无性能影响。 - PMU 初始化：
init_trap中通过crate::pmu::probe()检测 PMUv3 存在后才启用，EL0 可读 CTR_EL0 / PMCCNTR_EL0，代码注释充分说明了对perf stat的兼容性。 - 代码风格：与仓库现有 RK3588 驱动（cru、pinctrl、scmi）保持一致，模块边界清楚，
unsafe块有 SAFETY 注释。
残留风险
- 新增 board app（
sysbench-board）需要在物理板上部署后才能完全验证 governor 行为和 OPP 切换，QEMU 环境无法复现。当前 CI 的 StarryOS OrangePi-5-Plus check 已通过，板端验证风险可接受。 governor_poll的WINDOW_TICKS基于 10 ms/tick 假设（GOV_PERIOD_MS / 10），若 tick 频率改变需同步调整。当前仓库TICKS_PER_SEC = 100，一致。
重复/重叠分析
总结
本 PR 的质量良好，所有之前审查中提出的阻塞问题均已修复。DVFS 驱动设计合理，验证充分。批准合并。
Powered by deepseek-v4-pro
There was a problem hiding this comment.
审查结论：APPROVE ✅
本 PR 在 apps/starry/sysbench/ 和 apps/starry/sysbench-board/ 下新增 StarryOS 的 sysbench QEMU/OrangePi-5-Plus 基准测试场景、板端采样与对比工具链，在 drivers/ax-driver 中加入 RK3588 CPU DVFS 驱动（SCMI 时钟 + PMIC 电压校准 + ondemand governor），在 components/axcpu 中启用 EL0 可读的 PMU 周期计数器，在 os/arceos/modules/axtask 中加入每个 CPU 的调度忙碌 tick 计数器供 governor 采样。
上轮审查阻塞项的解决情况
上一轮审查（HEAD 07ef8bc）及更早（HEAD f9a195ff）的三个阻塞问题在当前 HEAD 0e2e3e0b 均已解决：
- OPP 事务性（
f9a195ff）：apply_opp现在返回#[must_use] bool，在每个方向（升频先电压后频率、降频先频率后电压）都在第一步失败时跳过第二步，且governor_poll仅在apply_opp返回true后提交IDX。失败时硬件状态保持安全（over-volted，没有 undervolt 窗口），软件IDX保留在最后确认的 OPP 上。✅ - Matrix 配置掩盖子测试失败（
07ef8bc）：qemu-aarch64-matrix.toml已改为fail=0; ... || fail=1; ... [ $fail = 0 ] && echo SYSBENCH_MATRIX_OK || printf 'SYSBENCH_%s\n' HAS_FAILURES，fail_regex包含SYSBENCH_HAS_FAILURES，四个子测试任一失败都能被 runner 捕获。✅ - 单元测试
envelope_is_down_only_675_to_800失败（07ef8bc）：已重命名为envelope_is_675k_to_1000k_inclusive，匹配已提升至 1.0V 的VDD_CEIL_UV。✅
CI 状态
当前 HEAD 共 59 个 check：29 成功、29 跳过（矩阵/path filter 预期行为）、1 取消（aka-00-sg2002 板卡，非本 PR 修改范围）、0 失败。StarryOS OrangePi-5-Plus 自托管板卡 check 成功。
代码质量
- DVFS 驱动：
cpufreq.rs的 governor 逻辑清晰（per-core 打分、快攻慢退、事务性 OPP 应用），与 Linux schedutil/ondemand 模式对齐。 - PMIC 驱动：
pmic_i2c.rs/pmic_spi.rs包含完整的寄存器级文档和单元测试，电压编码/解码边界条件覆盖充分。 - axtask 改动：
BUSY_TICKS使用Relaxed原子量在 tick handler 中递增，开销极小；cpu_busy_ticksAPI 安全返回 0 对越界 CPU。 - PMU 初始化：通过
pmu::probe()检测 PMUv3 存在后才启用，EL0 可读 PMCCNTR_EL0。 - 模块边界：cpufreq、pmic_i2c、pmic_spi 均受
rk3588-cpufreqfeature gate 保护；AArch64 内联汇编由#[cfg(target_arch = "aarch64")]条件编译隔离。 - 无
[patch.crates-io]：已确认。
重复/重叠分析
- #1657（cpufreq 实现）是本 PR 明确叠加的依赖，已带入当前 HEAD，属于依赖关系而非重复。
- #1656（线程分布修复）是互补的调度修复。
- 未发现其他可替代本 PR app 工作流的开放实现。
残留风险
- 新增 board app（
sysbench-board）的完整 governor 行为和 OPP 切换需要物理板验证，QEMU 无法复现。当前 CI 的 OrangePi-5-Plus check 已通过，风险可接受。 governor_poll的WINDOW_TICKS基于 10 ms/tick 假设（TICKS_PER_SEC = 100），与当前仓库一致。
总结
本 PR 质量良好，所有之前审查中提出的阻塞问题均已修复。DVFS 驱动设计合理，代码注释充分，模块边界清晰。批准合并。
Powered by deepseek-v4-pro
…tate machine Blocker 1 (IRQ latency): the RK3588 PMIC I2C/SPI drivers held a `SpinNoIrq` across the entire slow, busy-waiting hardware transaction, disabling local IRQs for the whole PMIC poll. Switch both `pmic_i2c` and `pmic_spi` to `SpinNoPreempt` so IRQs stay enabled during the poll while a task switch still cannot interleave mid-transaction. Sound because the PMIC lock is never taken from an interrupt handler: every caller runs in the boot probe (`align_rail_voltages_to_opp`) or the sleepable `cpufreq` governor/calibration task, so an IRQ arriving mid-transaction can never re-enter and self-deadlock. Blocker 2 (untested state-machine fixes): extract the pure, behavior-preserving decision logic and add host `#[cfg(test)]` unit tests. - `apply_opp` now runs its two levers through pure `apply_step_order` + `run_apply_steps`: ordering (up = voltage-then-clock, down = clock-then-voltage) and the transactional stop-at-first-failure / commit-only-on-both-success rule that gates the governor's `IDX` advance. Hardware writes and their exact no-undervolt logs are unchanged. - `governor_poll`'s up/down/hold/prime decision is extracted to pure `next_opp_idx(core_pcts, cur, ladder_len, priming)`; the stateful per-core LAST_BUSY loop and logging are unchanged. - Tests cover: apply ordering + all partial-failure paths (no phantom OPP), governor fast-attack / one-step decay / hold / floor / priming, and the OPP tables staying within each rail's PMIC voltage envelope and boot-safe ring ceiling.
There was a problem hiding this comment.
本 PR 新增 StarryOS sysbench 的 QEMU/OrangePi-5-Plus 场景、板端采样与对比资料，并将 RK3588 的 SCMI/PMIC DVFS、AArch64 PMU 计数及 axtask busy-tick 接入内核，以验证 big.LITTLE 性能和调度扩展性。它不是隔离的文档改动：会影响真实板端 CPU 时钟、电源轨、调度负载统计和用户态 PMU 可见性。
feature-development.md 适用：这是共享驱动、平台能力和用户可运行 board app 的高风险扩展。PR 说明和 apps/starry/sysbench-board/{README,GOVERNOR-VALIDATION,COMPARISON}.md 给出了 OrangePi-5-Plus 的目标、测量方法、非目标及板端结果；apps/starry/README.md 的 app/test-suit 分层也已遵守。实现采用驱动负责 OPP 策略与硬件动作、内核负责可睡眠的采样循环，依赖方向合理；但 A55 电压确认问题使该设计目前不能保证安全。
阻塞项见行内评论：A55 的 RK806 写入没有可靠读回，却被当成已确认的 OPP 电压切换；随后可以提高 SCMI 时钟并提交软件 OPP 索引，存在在旧低电压上调频及状态失真的风险。请先以可验证的硬件证据闭合该边界，或在此之前禁用 A55 动态 OPP。
验证与 CI：review_pr_helper.py test、prepare-review、脚本语法检查、Python/TOML 解析已通过。当前 HEAD 的组织 CI check-runs 为 65 个，33 个成功、32 个按矩阵/路径条件跳过，未见失败；因此未重复执行已由 CI 覆盖的本地 Rust/QEMU 测试。新增 board 工作流需要真实 OrangePi-5-Plus 与已部署 rootfs，本环境无法复跑；现有 CI 成功不能替代对 PMIC 写入失败/未生效分支的确定性覆盖。
已审阅此前技术反馈：旧的 OPP 事务性问题在 A76 read-back 路径已得到改进，matrix 子测试失败传播和电压包络测试也已随当前 HEAD 修正；Copilot 留言仅为配额提示。检索并比较了 #1657（本 PR 已合入的 cpufreq 依赖）和 #1656（互补的 SMP 分布修复），二者不是重复实现。除本评论外，没有新增的未解决重复、CI 失败或测试发现。
Powered by gpt-5.6-terra
| fn set_voltage(self, uv: u32) -> bool { | ||
| use super::{pmic_i2c, pmic_spi}; | ||
| match self { | ||
| Cluster::A55 => pmic_spi::force_write_dcdc2(uv), |
There was a problem hiding this comment.
阻塞 / 硬件事务性： 这里把 force_write_dcdc2 当作已确认的电压切换，但该函数的注释明确说明 RK806 的读回路径仍不可用，返回值只代表 SPI 传输完成；当写入没有实际到达 PMIC 时它仍可能成功返回。随后 apply_opp 会继续提高 SCMI ring 并提交 IDX，于是 A55 上调可能在旧的较低电压运行，软件状态也会伪称目标 OPP 已生效。这违反了本 PR 声明的“事务性/不欠压”约束。请在能读回或用等价硬件证据确认 DCDC2 电压前禁用 A55 的动态 OPP；或仅在确认电压已生效后设频并更新 IDX。
… writes The RK806 DCDC2 rail (A55) accepts writes (rail-alignment freq drops confirm) but its SPI read is a hardware scope-wall — MISO never feeds the shift register, so a dynamic voltage write cannot be read back to confirm the rail reached target. Per review, scaling the A55 voltage on such an unconfirmable write risks committing an OPP whose rail never arrived (undervolt). Cluster-split the readiness: the A76 rails read back over I2C and keep the full voltage lever; the A55 cluster forgoes it. A55 is pinned to the boot-confirmed 675 mV rail and scales only its SCMI PVTPLL ring (408/816/1008 MHz). 675 mV over-volts every ring <= 1008 (board-measured to deliver 1008 exactly), so no A55 rung can undervolt regardless of what the unconfirmable SPI write did. - Truncate A55_OPPS to the three 675 mV ring-only rungs (drop the voltage-scaled 1212-1523 MHz rungs). The canonical A55 voltages (mainline rk3588-opp.dtsi cluster0: 1200@712.5, 1416@762.5, 1608@850, 1800@950; ceiling 950 mV) are Linux-rated but still need a trusted RK806 write-back before we drive them. - Add Cluster::voltage_managed(); apply_opp treats the voltage step as a confirmed no-op for ring-only clusters, so the ordered/transactional apply is unchanged but issues no dynamic A55 SPI write. - Lock the invariant with a host test (a55_ladder_is_ring_only_on_the_boot_rail). 33 host tests pass; fmt + clippy clean.
81a605d to
e49c1a5
Compare
A55 欠压阻塞项已修复（rebase 到 #1657 最新 head）本 PR 之前带着一份过时的 DVFS 驱动副本（落后 #1657 若干提交）。已将本 PR 的 3 个 app/harness 提交 rebase 到 #1657 的最新 head（
驱动文件现与 #1657 |
There was a problem hiding this comment.
本 PR 新增 StarryOS sysbench 的 QEMU/OrangePi-5-Plus 场景、板端采样/部署 harness 和结果材料，并叠加 RK3588 cpufreq、PMU 及 axtask SMP 分配改动，用于验证 big.LITTLE 负载表现。变更并不隔离：除 app 工作流外，也影响真实板端的启动、调度和电源/频率路径。
book/guideline/feature-development.md 适用：这是共享驱动能力与用户可运行 board app 的组合功能（高风险硬件/平台部分）。PR 提供了问题、使用者、板端记录和同板 Linux 比较；实现采用“驱动纯策略/内核周期任务/app 场景”分层，避免 ax-driver 反向依赖 axtask。#1657 是明确的 stacked cpufreq 依赖，#1656 是互补的 SMP 初始分配修复；未发现可替代此 app/harness 的开放 PR。
已复核此前技术评论：OPP 事务提交、A55 ring-only 安全策略及 QEMU matrix 子测试失败传播均已在当前 head 中修复；Copilot 评论仅为额度提示。当前仍有下列阻塞项：提交的原始文本快照违反 diff hygiene。
验证：review_pr_helper.py test 和 prepare-review 通过；shell/Python 静态检查中发现 harness 脚本明确使用 Bash（以 bash 运行是有效的），未作为 POSIX sh 缺陷处理。远程当前 head 的 Actions workflow #29986572977 为 success；check-runs 共 59 个，30 success、29 为预期条件跳过、无失败（包括相关 self-hosted board 检查）。依用户要求，CI 已通过，未重复完整本地构建/QEMU。物理板流程受当前环境限制未复跑；修复后仍应按 README 完成一次 board 运行并确认 guest sentinel。
本地 git diff --check origin/dev...HEAD 失败并报出 733 条诊断，均来自新快照的空白/CRLF 问题；这不是基础设施或无关 CI 失败。除行内问题外，未保留其他阻塞结论。
Powered by gpt-5.6-terra
| Finished `release` profile [optimized] target(s) in 0.69s | ||
| warning: the following packages contain code that will be rejected by a future version of Rust: core v0.0.0 (/Users/jsph273/.rustup/toolchains/nightly-2026-05-28-aarch64-apple-darwin/lib/rustlib/src/rust/library/core), memchr v2.8.2 | ||
| note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 2` | ||
| Converting ELF to BIN format... |
There was a problem hiding this comment.
【阻塞｜diff hygiene】此原始串口快照以 CRLF 提交，导致 git diff --check origin/dev...HEAD 在新快照中报出大量 trailing whitespace；本行末尾也可见 \r。快照内容可以保留，但请将仓库中的文本规范化为 LF（若必须字节级保存原始数据，则改用明确的二进制/归档形式），以恢复可检查的干净补丁。
…transition A CLOCK_RATE_SET ack from SCMI is not proof the PVTPLL ring actually switched. governor_poll's apply_opp treated `set_clock_rate(...).is_some()` as a confirmed switch, so on a downshift (clock-then-voltage) it could go on to lower the rail while the clock was still high — the freq-high/voltage-low window the apply ordering exists to prevent. Confirm the clock like the boot `set_and_verify` already does: after the SET, read the rate back with `scmi::clock_rate` and require it to equal the request; only then is the clock step successful. Because the step is transactional and stops on failure, a downshift now reaches its voltage-lower step only once the clock is verified already lowered, and an unconfirmed clock leaves the rail untouched (over-volted for the old clock, never under-volted). Updated the apply_opp no-undervolt doc to state each step is read-back-confirmed. 33 host tests pass; fmt + clippy -D warnings clean.
e49c1a5 to
b424e2b
Compare
Diff-hygiene 已修复 + rebase 到 #1657 最新 head
|
There was a problem hiding this comment.
本 PR 新增了 StarryOS sysbench 的 QEMU/OrangePi-5-Plus 工作流、板端采样工具与快照，并带入 RK3588 DVFS、PMU 及调度忙碌 tick 支持；它会影响真实板卡的启动、供电及基准结果，并非隔离的文档改动。
阻塞项见行内评论：提交的默认 board 构建配置与该场景声明的 SMP-4 以及“8 核会 brownout”的硬件约束相矛盾，正常文档命令会以 8 核启动，可能在测试前复位或挂起，因而无法复现结果。
验证：review_pr_helper.py test、prepare-review、git diff --check origin/dev...HEAD、cargo fmt --check、所有新增 shell 脚本语法检查、Python 编译检查均通过；cargo test --manifest-path drivers/ax-driver/Cargo.toml --features rk3588-cpufreq --lib -- --nocapture 通过（33/33）。当前 HEAD 的组织 CI 已完成，59 个 check 中 30 个成功、29 个为条件跳过，未见失败；其中 OrangePi-5-Plus 自托管测试成功。未在本地重复 CI 已覆盖的 QEMU/板卡流程；新增 board 场景仍须在修复默认 CPU 数后以物理板验证最终标记。
已阅读此前技术评论：OPP 事务性、QEMU matrix 失败传播、PMIC 边界测试和快照 CRLF 问题均已在当前 HEAD 合理修复。Copilot 评论仅为配额提示。重复/重叠检查显示 #1657 的 cpufreq 实现是本 PR 已继承的前置改动，#1656 为互补的调度工作；未发现同等的开放 sysbench 场景。除行内问题外，没有其他阻塞结论。
Powered by gpt-5.6-terra
| "ax-driver/rk3588-cpufreq", | ||
| ] | ||
| log = "Info" | ||
| max_cpu_num = 8 |
There was a problem hiding this comment.
阻塞（板端可用性）：这里实际设成了 max_cpu_num = 8，但同一文件的注释和 README 都把该场景定义为 SMP-4，并明确记录当前 PSU 在八核同时运行时会 brownout。于是文档中的默认 board 命令会启动八核，可能在跑基准前复位或卡死，无法得到可复现结果。请先将默认配置改回已声明的 4 核；若确实要覆盖 8 核，则需要提交已验证的安全供电/启动配置，并同步修正文档和测试主张。
…ocument it Per review, the DVFS feature was never enabled in any board build/test/doc entry so CI only exercised the feature-off stub path. Enable it in the Orange Pi 5 Plus board config alongside the other default-on RK3588 hardware features (rknpu, rk3588-pwm), so the existing `Test starry self-hosted board orangepi-5-plus` entry builds and runs the governor on real hardware. It is fail-safe: if a PMIC bus does not come up, GOV_READY stays false and each cluster is left on its boot OPP. Add docs/rk3588-cpufreq.md with the reproducible enable command (`cargo xtask starry test board --board orangepi-5-plus`) and the observable governor/OPP verification: the boot arming log, per-cluster `gov:` OPP transitions, and cpuprobe `mhz_pmc` under load.
The committed raw serial-capture snapshots had CRLF line endings and trailing whitespace, which git diff --check / the review bot flag as diff-hygiene noise (366 trailing-whitespace + 1 blank-line-at-EOF). Convert CRLF->LF, strip trailing whitespace, and normalize the final newline. Captured content (line counts, values) is unchanged.
…nario The sysbench-board build config declared max_cpu_num = 8 while its own header comment, the README, and the scenario all state SMP-4 (and warn the board browns out / the smp8 boot is unproven at 8 cores). The documented deploy command would therefore boot 8 cores and reset/hang before the benchmark, making the results unreproducible. Set max_cpu_num = 4 so the committed config matches the documented, brownout-safe SMP-4 scenario.
b424e2b to
58366ce
Compare
board 构建配置 max_cpu_num 8→4 已修正 (commit
|
There was a problem hiding this comment.
本 PR 新增 StarryOS 的 sysbench QEMU/OrangePi-5-Plus 场景、板端采样脚本，以及 RK3588 DVFS、PMU 计数和 busy-tick 接入，用于获取 big.LITTLE 的可复现实测数据。改动并非隔离：会影响 StarryOS 的启动任务、调度负载采样、AArch64 PMU 和真实板端的 CPU 时钟/电压；新增 app 工作流本应在 QEMU 覆盖 sysbench 的线程/互斥量/futex 路径。
存在一个阻塞问题，详见行内评论：sysbench 的 aarch64 构建配置传入了 starryos 不支持的 feature，导致 README 所列的精确 QEMU 命令在启动 QEMU 前失败，新增场景及其声称的语义覆盖无法执行。
验证结果：review_pr_helper.py test、prepare-review、cargo fmt --all --check、git diff --check、TOML/Python/shell 检查均通过；cargo test --manifest-path drivers/ax-driver/Cargo.toml --features rk3588-cpufreq --lib -- --nocapture 为 33/33 通过，cargo clippy --manifest-path drivers/ax-driver/Cargo.toml --features rk3588-cpufreq -- -D warnings 通过；cargo xtask starry app list 能发现 sysbench 与 sysbench-board。用失败的 sysbench threads stub 复核 matrix 后，正确输出 SYSBENCH_HAS_FAILURES 而不会输出成功标记，先前的失败传播问题已解决。实际运行 cargo xtask starry app qemu -t sysbench --arch aarch64 已下载/准备 rootfs，但在构建阶段因行内问题失败，未进入 guest。
当前 HEAD 的 CI 共有 59 个 check，30 成功、29 条件跳过、无失败；成功的 Starry QEMU 覆盖为 riscv64/x86_64，未覆盖本 PR 新增的 aarch64 sysbench app 路径，因此不能证明该路径可用。OrangePi-5-Plus 的自托管 check 成功；本环境没有物理板，无法执行需部署后 rootfs 的 board workflow。
已复核之前的技术评论：OPP 事务性、A55 不可读回电压写、matrix 子测试失败传播、PMIC 边界测试、快照空白和 board 配置的 SMP-4 不一致都已在当前 HEAD 合理修复。Copilot 旧评论只是配额提示。重复/重叠分析中，#1657 的 cpufreq 实现是本 PR 已带入的依赖性部分重叠，#1656 的调度修复为互补；未发现与本 app 工作流重复的开放 PR。除行内问题外未发现其他未解决阻塞项。
Powered by gpt-5.6-terra
| # Mirrors test-suit/starryos/qemu-smp4/build-aarch64 (proven to boot 4 cores): | ||
| # max_cpu_num=4 + nvme root + virtio-net so `apk add sysbench` has networking. | ||
| features = [ | ||
| "ax-feat/display", |
There was a problem hiding this comment.
阻塞｜新增 QEMU 场景不可执行： 这里把 ax-feat/display 和 ax-feat/rtc 传给了 starryos 包，但该包并不定义这两个 feature。按 README 运行 cargo xtask starry app qemu -t sysbench --arch aarch64 会在启动 QEMU 前失败：the package 'starryos' does not contain these features: ax-feat/display, ax-feat/rtc，因此新增的 sysbench QEMU 语义覆盖实际上完全没有执行。请改用 StarryOS 构建配置接受的 feature 名称（或删除不需要的 display/RTC 项），并用该精确命令跑到 guest 的成功标记；若要持续支持 aarch64，也请让 CI 覆盖此路径。
…ime/*)
The sysbench aarch64 QEMU build config passed `ax-feat/display` and `ax-feat/rtc`,
which the `starryos` package does not define, so the documented
`cargo xtask starry app qemu -t sysbench --arch aarch64` failed before launching
QEMU ("the package 'starryos' does not contain these features"). Rename to the
valid `ax-runtime/*` names (matching test-suit/starryos/qemu/build-aarch64-
unknown-none-softfloat.toml, which boots 4 cores), so the new scenario actually
runs. Also fix the stale mirrored-config reference in the header comment.
修复 QEMU 场景的 feature 名（commit
|
There was a problem hiding this comment.
本 PR 新增 StarryOS 的 sysbench QEMU/OrangePi-5-Plus 场景、板端采样与比较文档，并叠加 RK3588 DVFS、AArch64 PMU 计数及 axtask busy-tick/调度分布改动，以取得 big.LITTLE 的可复现实测数据。它会影响板端 CPU 时钟/电压、启动任务、调度负载采样和 app 工作流，不是隔离的文档变更。
book/guideline/feature-development.md 适用：这是跨层的硬件/性能高风险能力。PR 已提供 app 文档、校准/比较记录与依赖说明；已核对 base 中不存在同名 sysbench/rk3588-cpufreq 实现，开放的 #1657 是本 PR 明确叠加的 cpufreq 依赖，#1656 是互补的调度分布修复，并非重复实现。当前阻塞点是提交的性能结论与可执行配置不一致，详见行内评论。
验证：review_pr_helper.py test、prepare-review、HEAD/工作树与 git diff --check origin/dev...HEAD 均通过；TOML 解析、bash 语法和 Python 编译检查通过。CI run #30065266774 针对当前 HEAD：组织 CI 的多数相关任务成功，路径检测、格式化/静态检查、标准测试及多项 QEMU/板卡任务成功；条件矩阵有预期 skipped。另有 Test axvisor self-hosted board asus-nuc15crh-linux 失败、OrangePi-5-Plus Starry board 任务取消；前者是未触及的 Axvisor/NUC 工作负载，后者未提供本 app 的 guest 结果，均不能作为新增 aarch64 sysbench app 的通过证据。当前 CI 没有执行本 PR 的 cargo xtask starry app qemu -t sysbench --arch aarch64 或提交的 board harness；本地实际 QEMU 未完成，因为 nightly/xtask 依赖下载在时间限制内未完成，不能替代运行证据。
已复核此前技术意见：OPP 事务性、A55 动态不可读回电压写、matrix 失败传播、PMIC 边界测试、快照 whitespace、board 配置的 SMP-4 不一致及 QEMU feature 名问题均在当前 HEAD 已合理处理；Copilot 旧评论仅为配额提示。没有待解决的其他技术 review thread。
剩余风险/测试缺口：除行内所述配置与性能结论矛盾外，物理板流程仍应在修复后按 README 的部署与运行命令获得当前 HEAD 的客体可见成功标记和与文档一致的 CPU 拓扑证据。
Powered by gpt-5.6-terra
| | cpu events/s, 1 thread | 271 | 300 | 974 | 3.2x | | ||
| | cpu events/s, 2 threads | 938 | 1471 | 1954 | 1.33x | | ||
| | cpu events/s, 4 threads | 2697 | ~3300 | 3894 | ~1.2x | | ||
| | **cpu events/s, 8 threads**| 3668 | **3991** | **5322**| **1.33x** | |
There was a problem hiding this comment.
阻塞（文档/可复现性）：这里把 t=8 的结果和“threads now use all 8 cores”描述为本 worktree 的 StarryOS 结果，但随 PR 提交的 board build 配置固定 max_cpu_num = 4，其注释还明确说明 SMP-8 会挂起/掉电。该配置的 init.sh 正是运行本 PR 的 harness；即使传入 --threads=8，也只能在四个已上线 CPU 上调度，无法复现表中的八核结论。这与性能声明必须有当前 head、可执行配置的证据相冲突。请提供并验证一个可运行的 SMP-8 配置，或删除/改写 t=8 与“all 8 cores”结论，并把历史数据标出准确的 kernel/config/commit，避免将其表述成提交后工作流可得到的结果。
…=8 research run Per review, the t=8 rows and the "all 8 cores" / "no brownout at threads=8" statements are not reproducible from the shipped board config, which pins max_cpu_num=4 (smp-8 brownout risk / unproven boot). Add a prominent reproducibility/provenance note attributing those numbers to the experimental max_cpu_num=8 + DVFS-ceiling research kernel on worktree-sysbench, clarify that the submitted init.sh reproduces the SMP-4 scaling curve, and qualify the two in-body claims accordingly. No data changed; only its provenance is made explicit.
修正 t=8 性能结论的可复现性/出处（commit
|
There was a problem hiding this comment.
本 PR 新增 StarryOS 的 sysbench QEMU/OrangePi-5-Plus 场景、板端采样/对比工具，并随堆叠提交引入 RK3588 DVFS、PMU 和 axtask 忙碌 tick。它会影响板端硬件电压/频率、调度负载计量及 app runner 的结果语义，并非隔离的文档改动。
feature-development.md 适用：这是共享的板卡硬件能力与用户可执行 app 工作流，按高风险特性审查；现有 README、DVFS 文档和板端记录构成设计/运行材料。starry/syscall.md 不适用，因为没有改变用户可见 syscall/Linux ABI 语义。
阻塞项见行内评论：板端 harness 会吞掉每个工作负载的失败并仍打印成功 sentinel，导致 ostool 将失败的 sysbench 运行判为成功。该问题使新增 board 工作流的回归覆盖不可用。
已核对此前评论：早期 OPP 事务、A55 未确认电压写、QEMU matrix 失败传播、测试边界、CRLF 和 SMP-8 配置问题均已在当前 HEAD 合理处理；Copilot 评论仅为额度提示。当前唯一未解决问题是本次板端失败传播。
验证：review_pr_helper.py test 与 prepare-review 均通过；工作区 HEAD 为 3c41cdd75987f8306cdd88ccda13c869790f88aa，git diff --check origin/dev...HEAD 无输出。CI 针对该 HEAD 的 workflow 已成功，61 个 checks 中 31 个成功、30 个为条件跳过，未发现 PR 相关失败（含 OrangePi-5-Plus 自托管检查）。遵循“CI 已通过无需重复完整本地测试”，只做了与结论直接相关的确定性验证：以始终返回 1 的 sysbench stub 运行 board harness，进程仍退出 0 并打印 SYSBENCH_BOARD_DONE，复现了失败被吞掉的问题。
测试/运行路径：QEMU case 有 cargo xtask starry app qemu -t sysbench --arch aarch64 与 matrix 命令；board case 由 cargo xtask starry app board -t sysbench-board ... 发现，物理板与已部署 rootfs 是该路径的环境前提。本环境无法替代物理板验证，但不影响上述本地可复现的失败传播缺陷。
重复与重叠：基线未包含等价 sysbench 场景；开放的 #1657 是本 PR 显式堆叠的 cpufreq 依赖，#1656 为互补的调度分布改动，未发现可替代本 app 工作流的重复实现。修复行内问题并在 board runner 中验证“任一子测试失败必使命令失败”后，可重新评估。
Powered by gpt-5.6-terra
| done | ||
|
|
||
| sync 2>/dev/null | ||
| echo SYSBENCH_BOARD_DONE |
There was a problem hiding this comment.
阻塞｜板端失败传播： 此脚本忽略所有 sysbench/taskset 命令的退出状态，最后无条件打印 SYSBENCH_BOARD_DONE；而 board 配置正是以该标记判定成功。将 sysbench 替换为始终返回 1 的 stub 后，脚本仍以 0 退出并输出成功标记，因此 CPU/threads/mutex/memory 任一子项失败都会被报告为通过。请逐项检查命令状态和解析结果，失败时输出唯一失败标记并以非零退出；仅在全部必需工作负载成功后打印 SYSBENCH_BOARD_DONE。
…-pass) The board harness ran each sysbench workload as `$(... 2>/dev/null | awk ...)`, discarding the exit code, and printed SYSBENCH_BOARD_DONE unconditionally — so a crashed/failed sysbench run still matched ostool's success_regex and was scored as a pass, making the board regression coverage useless. Route every workload through run_sb(), which runs it without a pipe (so $? is the real exit status), captures stdout in $OUT for the metric awk, and raises a fail flag on non-zero exit. At the end, if any workload failed, print the anchored SYSBENCH_BOARD_FAILED marker and exit non-zero instead of the DONE sentinel; add that marker to board-orangepi-5-plus.toml fail_regex (same anchored-marker pattern as SYSBENCH_MISSING). A fully-successful run's output is unchanged.
板端 harness 失败传播已修复（commit
|
There was a problem hiding this comment.
本 PR 新增 StarryOS 的 sysbench QEMU/OrangePi-5-Plus 场景、板端采样/对比工具与结果文档；同时携带 #1657 的 RK3588 cpufreq、PMU 与 axtask busy-tick 支持，以验证 big.LITTLE 调度和频率行为。它会影响板端时钟/电源轨、启动期任务和调度负载采样，并非隔离的文档改动；实现仍保持驱动核心、StarryOS 任务循环与 operator-facing apps/starry 场景的既有分层。
book/guideline/feature-development.md 适用：这是高风险的平台/硬件能力与用户可运行场景扩展。PR 描述、docs/rk3588-cpufreq.md、apps/starry/sysbench*/README.md 及校准/结果文档给出了问题、使用者、SMP-4 非目标/供电限制、QEMU 与实板边界、已选 SCMI+PMIC 方案和可复现命令；与 base、#1657（cpufreq，依赖/部分重叠）和 #1656（SMP 初始分布，互补）核对后未发现重复实现。
已核对此前所有技术性评论在当前 HEAD 的修复：OPP 仅在电压/SCMI 读回均确认后提交；A55 改为固定 675 mV 的 ring-only 路径，避免不可确认的动态电压写；matrix 任一子测试失败会输出失败标记；电压边界测试、快照 LF、board 默认 SMP-4 与 QEMU feature 名均已修正。Copilot 评论仅为配额提示；没有仍适用的未解决技术评论。
验证：当前 HEAD 的组织 CI 已完成，61 个 checks 为 31 success、30 条件性 skipped、0 failure（包含格式/静态检查以及已调度的 Starry/板端矩阵）；因此未重复执行完整本地 QEMU。另运行了 review_pr_helper.py test 与 prepare-review，git diff --check origin/dev...HEAD，新增 TOML 解析、shell bash -n 和 Python 编译检查，均通过。实板 sysbench 依赖 OrangePi-5-Plus、已部署 rootfs 与供电环境，当前环境不具备该硬件；PR 已将其作为 operator-facing board 流程记录，CI/静态验证不替代该物理测量。
新增 QEMU 矩阵通过显式成功/失败标记被 runner 发现，board 流程也使用最终唯一 sentinel；未发现剩余阻塞问题或测试发现性缺口。
Powered by gpt-5.6-terra
Adds a
sysbenchbig.LITTLE CPU benchmark for StarryOS and an RK3588board-measurement harness, plus a Linux-vs-StarryOS comparison.
apps/starry/sysbench/— QEMU sysbench app (apk add sysbench, LuaJIT works),cpu/threads/mutex/memory matrix.
apps/starry/sysbench-board/— OrangePi-5-Plus board case: glibc-dynamicdeploy, per-core
cpuprobe(core type + PMU MHz + affinity),membw, and aPOSIX-sh harness; a
sysbench-compare.shthat runs the identical matrix onboard Linux and StarryOS.
COMPARISON.md— with the DVFS governor and the axtask distribution fix,StarryOS
sysbench cput=8 reaches 3991 ev/s vs Linux 5322 (1.33x behind, downfrom ~33x when threads were flat); the residual is frequency ceiling, per-core
compute is at parity.
Depends on the RK3588 cpufreq PR (its board build config enables
ax-driver/rk3588-cpufreq) and benefits from the axtask distribution PR.