LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* RE: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
@ 2006-08-30 18:40 Pallipadi, Venkatesh
  2006-08-30 19:43 ` Matthew Garrett
  0 siblings, 1 reply; 24+ messages in thread
From: Pallipadi, Venkatesh @ 2006-08-30 18:40 UTC (permalink / raw)
  To: Adam Belay, Brown, Len
  Cc: ACPI ML, Linux Kernel ML, Dominik Brodowski, Arjan van de Ven

 

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Adam Belay
>Sent: Tuesday, August 29, 2006 1:51 PM
>To: Brown, Len
>Cc: ACPI ML; Linux Kernel ML; Dominik Brodowski; Arjan van de Ven
>Subject: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
>
>Hi All,
>
>This patch improves the ACPI c-state selection algorithm.  It also
>includes a major cleanup and simplification of the processor idle code.
>
>The new implementation considers the full menu of available c-states.
>Just as the previous implementation, decisions are primarily based on
>the residency time of the last c-state entry.  This is generally an
>effective metric because it allows for detection of interrupt activity.
>However, the new algorithm differs in that it does not promote 
>or demote
>through the c-states in succession.  Rather, it immediately jumps to
>whatever c-state has the best expected power consumption advantage for
>the predicted residency time (i.e. the previously measured residency).
>If the residency time is too short during a deep c-state 
>entry, then the
>cost of entering the state outweighs any power consumption advantage.
>Similarly, if a shallow c-state is entered and resident for an
>excessively long duration, then a potential opportunity to save more
>power is missed.
>
>The changes in this patch allow the ACPI idle processor mechanism to
>react more quickly to sudden bursts of activity because it can jump
>directly to whatever c-state is appropriate.  However, because of the
>"menu" nature of c-state selection, the code works best when ACPI
>implementations expose all of the c-states supported by hardware.
>
>The bus master activity mechanism has undergone similar improvements.
>During capability detection, the deepest c-state that allows bus master
>activity is determined.  BM_STS is then polled each time the ACPI code
>prepares to enter a c-state.  If bus master activity is detected, then
>the previously mentioned bus master capable c-state becomes the deepest
>c-state allowed for that quantum.  In contrast, the old implementation
>would permit bus master activity to cause a promotion from one C3-type
>state to the next shallower C3-type state, imposing 
>unnecessary latency.
>As a further optimization, BM_STS is cleared each time
>acpi_processor_idle() is entered.  This prevents any stale bus master
>status from affecting c-state policy, as it may have occurred long ago
>during scheduled work.
>
>Finally, it's worth mentioning that the bulk of c-state policy
>calculations have been moved to take place before c-states are entered.
>This should further reduce exit latency when returning from a c-state.
>
>This algorithm has not yet been carefully benchmarked (e.g. bltk or
>power meters).  However, I can say with some confidence that it saves a
>small amount more power during an idle workload and a larger 
>amount more
>power during typical user-input oriented workloads such as word
>processing.
>
>I would really appreciate any comments, suggestions, or testing.
>

Nice changes. Will test and let you know how it goes.

While we are at cleaning up the code, I think it will be much better to 
move out C-state policy out of this acpi code altogether. We should have

just a generic interface, where any low level driver (acpi) can 
register/unregister a idle routine with latency, power and other 
characteristics (BM_STS). That way the policy can be generic and 
out of ACPI code. We had a patch earlier that does something like this
here:
http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg00129.html
http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg00130.html
But, that did not go anywhere at that time. Probably we can do some 
cleanup like that, along with this patch....

Thanks,
Venki

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2006-09-14 11:30 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-08-30 18:40 [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements Pallipadi, Venkatesh
2006-08-30 19:43 ` Matthew Garrett
2006-08-31 23:13   ` Bjorn Helgaas
2006-09-01  0:30     ` [OLPC-devel] " Jim Gettys
2006-09-01  3:53       ` Len Brown
2006-09-01  4:12         ` Matthew Garrett
2006-09-01 15:51           ` Jordan Crouse
2006-09-01 13:14         ` [OLPC-devel] Re: [RFC][PATCH 1/2] " Carl-Daniel Hailfinger
2006-09-01 21:52         ` Andi Kleen
2006-09-01 22:57           ` Alan Cox
2006-09-04 13:13         ` Pavel Machek
2006-09-04 13:09       ` Pavel Machek
2006-09-05 14:31         ` Jim Gettys
2006-09-06 10:37           ` Pavel Machek
2006-09-06 14:58             ` Jordan Crouse
2006-09-12  9:21               ` Pavel Machek
2006-09-12 18:14                 ` Jim Gettys
2006-09-12 18:27                   ` Mitch Bradley
2006-09-12 20:18                   ` Jordan Crouse
2006-09-14  9:20                     ` Pavel Machek
2006-09-14  9:18                   ` Pavel Machek
2006-09-14 11:29                     ` Jim Gettys
2006-09-06 15:19             ` [OLPC-devel] Re: [RFC][PATCH 1/2] " Jim Gettys
2006-09-12  9:21               ` Pavel Machek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).