AMD CPU睿频失效与Intel平台FPS波动问题技术求助

Intel平台帧率波动（56-64FPS，旧版本也出现该问题） #

• 检查系统定时精度：内核5.15到6.x可能调整了时钟源或tick机制，执行cat /sys/devices/system/clocksource/clocksource0/current_clocksource查看当前时钟源，cat /proc/timer_list分析定时器精度。若模拟器依赖系统定时控制帧率，精度变化会直接导致波动。
• 验证线程绑定效果：未绑定固定核心的线程可能被内核调度在多核心间迁移，引发缓存失效和延迟。用taskset -p <模拟器PID>查看当前绑定状态，测试手动绑定到单核心（taskset -c 0 <模拟器启动命令>）后观察帧率稳定性。
• 排查后台抢占干扰：内核6.x可能调整了后台进程调度优先级，即使用户态进程优先级较高，也可能被系统线程抢占。用top -H -p <模拟器PID>查看线程实时CPU占用，搭配perf top定位系统层面的热点进程/函数，确认是否存在频繁抢占。
• 优化帧率控制逻辑：若模拟器使用usleep/nanosleep做帧率控制，内核6.x的睡眠精度可能变化。建议替换为clock_nanosleep的绝对定时模式（指定TIMER_ABSTIME参数），减少累积误差。

AMD平台（Ubuntu 22.04+内核6.5）无法触发睿频、线程负载<99%、6809模拟频率不达标 #

• 确认睿频系统配置：先排除系统层面的限制，执行cpupower frequency-info查看当前频率范围、governor状态，cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq检查是否被锁在基准频率。内核6.x默认可能启用amd_pstate=passive驱动，而5.15版本可能使用acpi_cpufreq，可尝试在启动参数中添加amd_pstate=active或acpi_cpufreq强制切换驱动。
• 定位线程负载不满的根源：线程负载未达100%说明存在主动等待或阻塞。用perf record -g -p <模拟器PID>采集调用栈，通过perf report分析等待来源——是IO等待、锁竞争，还是模拟器内部定时逻辑导致的主动睡眠？比如模拟循环中若睡眠逻辑在新内核下提前触发，会直接限制负载，进而无法触发睿频。
• 调整线程调度属性：提升模拟器线程优先级（renice -n -20 <模拟器PID>）并绑定到单核心，避免调度迁移。同时检查/sys/devices/system/cpu/cpu*/energy_performance_preference的值，设置为performance（echo performance > /sys/devices/system/cpu/cpu*/energy_performance_preference），确保能耗策略优先性能。
• 对比新旧内核调度行为：用trace-cmd跟踪调度事件，对比5.15和6.5内核下模拟器线程的调度延迟、唤醒时机。执行trace-cmd record -e sched_switch -e sched_wakeup -p <模拟器PID>采集数据，再用trace-cmd report分析线程是否被频繁唤醒/抢占，或调度器是否误判CPU idle状态导致睿频无法触发。

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