From: Philip Guenther Subject: Re: powersave CPU policy To: "Lorenz (xha)" , OpenBSD tech Date: Wed, 15 May 2024 00:19:12 -0700 On Tue, May 14, 2024 at 6:54 PM Theo de Raadt wrote: > Kirill A. Korinsky wrote: > > > On Wed, 15 May 2024 00:53:37 +0100, > > "Theo de Raadt" wrote: > > > > > > > This patch dynamically removes CPU cores when the system is idle to > prevent > > > > the scheduler from using them for any task, i.e. assuming the > hardware puts > > > > unused CPU to sleep to save some power. > > > > > > I am pretty sure that assumption is incorrect. There is some logic for > > > choosing Cx states for cpus, but I very much doubt that a deep-sleep > mode > > > is chosen. > > > > > > > It depends on the supported method to idle at acpicpu. The code achieves > > that CPU goes to idle via acpicpu_idle, which does MWAIT or HALT for the > > best available (supported?) C-state. > > Actually, in a seperate conversation I've had, it isn't choosing the best > state *for this*. It looks like it always chooses a come-back-quickly > state. > Yeah, mostly. acpicpi_idle() has nothing to tell it why the cpu is being idle so it will use the same logic for this as it does for when a CPU goes idle because your web browser is waiting for a response from a web-server...which is just a really simple (aka dumb) decaying average of how long it stayed idle when this function was previously called compared to the C-state latencies, such that it was idling longer recently then it'll idle deeper now. (With dynamic clock interrupts, that may actually result in it going to deep C-states only after some activity so it can wake up and see that it was idle for a long time. :-| Indeed, it really needs to calculate a function of energy use and latency choice vs how long to the next clock alarm to see which state is best to drop into...and by how much it should ask for an early alarm so that it can come out of the C-state in time for when the *real* target time is.) Philip Guenhter