On Thu, Oct 09, 2014 at 10:34:33AM -0700, Mike Turquette wrote: > Quoting Peter Zijlstra (2014-10-09 02:00:24) > > On Wed, Oct 08, 2014 at 04:28:36PM -0700, Mike Turquette wrote: > > > > Yeah, like hell no. We do not want modules to affect scheduler > > > > behaviour. > > > > > > If a CPUfreq driver is the best place to know how frequency affects the > > > capacity of a CPU for a given system, are you suggesting that we must > > > compile that code into the kernel image instead of it being a loadable > > > module? > > > > Ideally we'll end up doing away with the cpufreq policy modules and > > integrate the entire thing into the scheduler. > > I said "CPUfreq driver", not "CPUfreq governor". Certainly the scheduler > can pick a capacity state/p-state/frequency and, in doing so, replace > the CPUfreq policy bits. > > My question above was about the necessity to select the right CPUfreq > driver at compile-time and lose support for those drivers to be loadable > modules. Sounds like a bad idea.
Drivers should not care one way or another. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
