Le 03/06/2024 à 14:18, Kirill A. Korinsky a écrit :
> On Wed, 15 May 2024 08:19:12 +0100,
> Philip Guenther <guenther@gmail.com> wrote:
>>
>> 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.)
>>
> 
> Here an updated version of the diff which I run for last two weeks I assume.
> 
> The main differences is adding into acpicpu.c enforcing the deepst C-state
> for shutdown CPU.
> 
> I've tested that this logic works by inverting it (the lightest C-State) and
> confirm how fast battery is drawn on my machine.
> 
> Anyway, this code seems stable, I've tested for more than a week without
> reboot with tons of ZZZ and zzz, and it works well. No crash, no issue.
> 
> And all system's responsiveness that I've traded off is not noticable after
> few hours (or days) of using, and rigth now I just use it.
> 

Did you measure the gain? If so, can you share your test protocol and results?