如何针对特定核心禁用Linux深度C状态及PM QoS文件相关疑问

Linux系统中CPU运行在不同节能状态（C状态），范围从C0到Cn：C0是性能最高的状态，但功耗也更高。若要最大化性能，可禁用向更深层C状态的切换，主要有两种方式：

• 全局方式：向/dev/cpu_dma_latency文件写入0，影响所有CPU
• 单CPU方式：向/sys/devices/system/cpu/cpu<cpu_id>/power/pm_qos_resume_latency_us文件写入"n/a"，针对特定CPU核心

针对上述场景，以下是对应技术疑问的解答：

问题1：除作用核心数量外，pm_qos_resume_latency_us与cpu_dma_latency作用是否完全相同？命名差异原因？ #

两者作用并不完全相同，核心差异如下：

• 约束对象与范围：
  • cpu_dma_latency是系统级全局PM QoS约束，延迟限制会作用于所有CPU，同时间接影响依赖CPU响应的DMA设备行为——最初设计是为了防止CPU进入过深C状态，导致DMA操作因CPU无法及时唤醒而超时。
  • pm_qos_resume_latency_us是单CPU核心级的唤醒延迟约束，仅针对指定CPU核心，直接限制该核心能进入的C状态深度，确保核心能在设定延迟内从节能态恢复到C0。
• 触发场景：前者更多是为外设DMA需求设计的全局约束，后者则是直接针对单CPU性能优化的精准控制。

命名差异的原因：

• dma latency：该接口最初为解决DMA设备兼容性问题而生，核心诉求是保证DMA操作的延迟在可接受范围内，因此命名突出其与DMA的关联。
• resume latency：这个sysfs节点直接面向CPU自身的唤醒延迟控制，命名清晰体现其作用——约束CPU从节能态恢复（resume）到运行态的最大延迟。

问题2：pm_qos_resume_latency_us是否遵循cpu_dma_latency的文件描述符机制？关闭其FD是否销毁关联PM QoS请求？ #

两者的机制完全不同：

• cpu_dma_latency是字符设备接口，依赖文件描述符管理PM QoS请求：打开文件时创建独立的PM QoS请求，写入数值设置延迟约束，关闭文件描述符则销毁对应的请求；多个进程可通过各自FD创建独立约束，系统取最严格的限制生效。
• pm_qos_resume_latency_us是sysfs节点，操作是即时修改对应CPU的全局PM QoS约束值：写入"n/a"会解除该CPU的延迟限制（或设置为无约束），写入数值则设置最大唤醒延迟。关闭该文件的描述符不会销毁任何请求，因为sysfs的修改直接生效并持久化，直到再次写入新值或系统重启，无需通过保持FD维持约束。

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