LKML Archive on
help / color / mirror / Atom feed
From: "Pallipadi, Venkatesh" <>
To: "Adam Belay" <>, "Brown, Len" <>
Cc: "ACPI ML" <>,
	"Linux Kernel ML" <>,
	"Dominik Brodowski" <>,
	"Arjan van de Ven" <>
Subject: RE: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
Date: Wed, 30 Aug 2006 11:40:16 -0700	[thread overview]
Message-ID: <> (raw)


>-----Original Message-----
>[] 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
>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
But, that did not go anywhere at that time. Probably we can do some 
cleanup like that, along with this patch....


             reply	other threads:[~2006-08-30 18:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 18:40 Pallipadi, Venkatesh [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2006-08-29 20:51 Adam Belay
2006-09-04 12:59 ` Pavel Machek
2006-09-05  2:19   ` Adam Belay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='RE: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).