Re: [PATCH] ACPI / idle: override c-state latency when not in conformance with s0ix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 12, 2021 at 4:47 AM Limonciello, Mario
<Mario.Limonciello@xxxxxxx> wrote:
>
> > > In processor_idle.c target residency is calculated by exit latency multiplied by
> > > a latency factor parameter (2 by default).  So when these systems have the
> > buggy
> > > _CST C2 value of 400, that's where the 800 comes from for residency, not
> > _LPI.
> >
> > Yes, that's right, sorry for the confusion.
> >
> > My point was mostly whether or not it would be sufficient to swap the
> > values for the last two states or if some new values needed to be used
> > and the answer appears to be the latter.
> >
> > So I don't see any way to address this that would be cleaner than the
> > quirk mechanism as proposed.
>
> The root of the problem is that the states get skipped.  So yes technically
> your suggestion of swapping the values of the last two states would be
> enough to avoid this issue as well.
>
> My thought is to do it by checking whether all the latencies are arithmetic
> progressions and if not then emit a notice this is a FW bug and sort at the
> end of acpi_processor_power_verify(pr).  This would be done on all systems.

Sounds reasonable to me.

> Let me know if that sounds good or if you would prefer to stick to the quirk
> approach as proposed or something hybrid.

Well, I prefer to avoid adding quirks if poss, because they become
pure technical debt when the quirked systems get out of use (and
there's no good way to determine whether or not this has already
happened).



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux