这种设计带来的好处是使得 governor 和 CPU 相关的变频驱动程序的开发可以相互独立进行，并在最大限度上实现代码重用，内核开发人员在编写和试验新的 governor 时不会再陷入到某款特定 CPU 的变频技术的硬件实现细节中去，而 CPU 生产厂商在向 Linux 内核中添加支持其特定的 CPU 变频技术的代码时只需提供一个相对来说简单了很多的驱动程序，而不必考虑在各种不同的应用场景中如何选择合适的运行频率这些复杂的问题。

　　内核中的 cpufreq 子系统通过 sysfs 文件系统向上层应用提供了用户接口，对于系统中的每一个 CPU 而言，其 cpufreq 的 sysfs 用户接口位于 /sys/devices/system/cpu/cpuX/cpufreq/ 目录下，其中 X 代表 processor id ，与 /proc/cpuinfo 中的信息相对应。以cpu0 为例，用户一般会在该目录下观察到以下文件：

　　$ ls -F /sys/devices/system/cpu/cpu0/cpufreq/

　　affected_cpus

　　cpuinfo_cur_freq

　　cpuinfo_max_freq

　　cpuinfo_min_freq

　　ondemand/

　　scaling_available_frequencies

　　scaling_available_governors

　　scaling_cur_freq

　　scaling_driver

　　scaling_governor

　　scaling_max_freq

　　scaling_min_freq

　　stats/

　　这其中的所有可读文件都可以使用 cat 命令进行读操作，另外所有可写文件都可以使用 echo 命令进行写操作。其中cpuinfo_max_freq 和 cpuinfo_min_freq 分别给出了CPU 硬件所支持的最高运行频率及最低运行频率， cpuinfo_cur_freq 则会从 CPU 硬件寄存器中读取 CPU 当前所处的运行频率。虽然 CPU 硬件支持多种不同的运行频率，但是在有些场合下用户可以只选择使用其中的一个子集，这种控制是通过scaling_max_freq 和 scaling_min_freq 进行的。Governor在选择合适的运行频率时只会在 scaling_max_freq 和scaling_min_freq 所确定的频率范围内进行选择，这也就是scaling_available_frequencies 所显示的内容。与cpuinfo_cur_freq 不同， scaling_cur_freq 返回的是cpufreq 模块缓存的 CPU 当前运行频率，而不会对 CPU 硬件寄存器进行检查。 scaling_available_governors 会告诉用户当前有哪些 governors 可供用户使用，而 scaling_driver 则会显示该 CPU 所使用的变频驱动程序。 Stats 目录下给出了对 CPU 各种运行频率的使用统计情况，例如 CPU 在各种频率下的运行时间以及在各种频率之间的变频次数。 Ondemand 目录则与 ondemand governor 相关，在后文会进行相应的介绍。大电流电感

 3/7   首页 上一页 1 2 3 4 5 6 下一页 尾页