Andrew Doran writes: > On Wed, Jan 22, 2020 at 10:08:16AM +1100, matthew green wrote: > > > Andrew Doran writes: > > > I also recommend disabling ACPI idle, at least until it can be made less > > > aggressive by default. It causes a significant slowdown. It can be done > > > with detaching all acpicpu devices using "drvctl -d" on each. > > > > this disables cpufreq support, doesn't it? that seems like > > an unfortunate side effect.. > > I dunno, I assume so. It seems like a tricky one to solve. > > I think we could do with a heuristic that does a "fast idle" used when the > system is busy and a "low power idle" when things have gotten quiet. And > the heuristic likely needs to be controllable with sysctl to suit > preferences (power consumption, performance). > > We probably also want to take a CPU in low power idle out of > kcpuset_running, but that imposes its own penalty on x86 because it then > goes from using broadcast IPIs to sending directed IPIs to every CPU; > needs to be tried. > > Also I don't know what to do about HyperThreading; it'd be nice if ACPI had > the smarts to handle it. > > My problem with this one is I don't know what I'm missing here... Maybe > time for a mail.
if machdep.idle-mechanism had a settable by user component, like the way that that cpufreq provides 'available' and 'current' nodes, it would be probably easy. .mrg.