LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: "Adam Belay" <abelay@novell.com>, "Brown, Len" <len.brown@intel.com>
Cc: "ACPI ML" <linux-acpi@vger.kernel.org>,
	"Linux Kernel ML" <linux-kernel@vger.kernel.org>,
	"Dominik Brodowski" <linux@dominikbrodowski.net>,
	"Arjan van de Ven" <arjan@linux.intel.com>
Subject: RE: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
Date: Wed, 30 Aug 2006 11:40:16 -0700	[thread overview]
Message-ID: <EB12A50964762B4D8111D55B764A845484D316@scsmsx413.amr.corp.intel.com> (raw)

 

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

             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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=EB12A50964762B4D8111D55B764A845484D316@scsmsx413.amr.corp.intel.com \
    --to=venkatesh.pallipadi@intel.com \
    --cc=abelay@novell.com \
    --cc=arjan@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --subject='RE: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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