Dirk, I applaud the work you are doing. In general I believe it is important to separate policy (governor and its settings) from the driver, particularly so as different end-users have very different goals for power management. Not everyone is trying to maximize performance per watt per se (in fact probably rather few end users are doing so literally). In server applications, for example, the first priority is typically maximum performance when under heavy load, and the second priority is minimum power consumption at idle. There may not ever be a benefit for choosing one of the middle clock states. The OnDemand governor with the sampling_down_factor set to ~100 can do quite well at this, at least compared to implementations prior to yours. Another consideration is that just blindly trying to run flat out all the time (e.g. the old performance governor approach) bumps you up against your thermal limits and can actually slow you down, vs. intelligently powersaving idle hardware threads -- so a user who totally aims for performance with no regard for power savings cannot avoid must paying some attention to power management. So what you have sounds like both a new driver (very important) and a new governor (also potentially very useful), with some of the dynamic portions of power management handled by the hardware itself. Ideally the new driver would be separated from the new governor in a somewhat modular way (so that implementation and policy can be separated). And ideally it would be nice if the new driver can be compatible with the existing governor by exposing an ability to set and report current frequencies. But if this is impractical or pointless for Sandy Bridge, so be it. I expect your new governor probably could not sit on top of any of the existing drivers, but some of the existing drivers could perhaps be enhanced to provide the necessary hooks, and it would be bad to have to implement the same policy framework over and over for all past and future hardware drivers that want to benefit from your work. So outside of a research kernel, I don't think having a "cpufreq/snb" directory is a good place to expose tuning parameters, the exposed interface should be generalized as much as possible and not be so implementation-specific. In the long run both integrators and maintainers of Linux distributions are going to insist on a generic interface that can work across the vast majority of modern hardware, rather than cater to a special case that only works on one or CPU families, even if those families are particularly important ones. David C Niemi On 12/05/12 14:01, dirk.brandewie@xxxxxxxxx wrote: > From: Dirk Brandewie <dirk.brandewie@xxxxxxxxx> > > This driver provides a P state driver for Sandybridge and Ivybridge > processors. > > Motivation: > The goal of this driver is to improve the power efficiency of > Sandybridge/Ivybridge based systems. As the investigation into how to > achieve this goal progressed it became apparent (to me) that some of the > design assumptions of the cpufreq subsystem are no longer valid and > that a micro-architecure specific P state driver would be less complex > and potentially more effiecent. As Intel continues to innovate in the > area of freqency/power control this will become more true IMHO. > > General info: > The driver uses a PID controller to adjust the core frequency based on > the presented load. The driver exposes the tuning parameters for the > controller in the /sys/devices/system/cpu/cpufreq/snb directory. The > controller code is being used in PI mode with the default tuning > parmeters. > > Tuning parmeters: > setpoint - load in percent on the core will attempt to maintain. > sample_rate_ms - rate at which the driver will sample the load on the core. > deadband - percent ± around the setpoint the controller will > consider zero error. > p_gain_pct - Proportional gain in percent. > i_gain_pct - Integral gain in percent. > d_gain_pct - Derivative gain in percent > > To use the driver as root run the following shell script: > #!/bin/sh > for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > do > echo snb > $file > done > > Limitations: > > ATM this driver will only run on SandyBridge systems testing on > Ivybridge systems is not complete. > > Open Questions: > > What is the correct way to integrate this driver into the system? The > current implementation registers as a cpufreq frequency governor, this > was done to streamline testing using cpufreq to load/unload governors. > > What tuning parameters should be exposed via sysfs (if any)? ATM all > the PID parameters are exposed to enable tuning of the driver. > .... -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
