re: CVS commit: src/sys/uvm

[matthew green <mrg%eterna.com.au@localhost>]

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.