public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state
@ 2005-08-31 21:09 Venkatesh Pallipadi
       [not found] ` <20050831140933.A12497-39QZ/XbsZ5/mO6KZMuUCQVaTQe2KTcn/@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Venkatesh Pallipadi @ 2005-08-31 21:09 UTC (permalink / raw)
  To: cpufreq, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
  Cc: Dave Jones, Dominik Brodowski, Len Brown, Rajesh Shah


ACPI 3.0 (http://www.acpi.info) adds new methods with which BIOS can communicate
P-state dependency domains (List of CPUs that share a common P-state) to
the OS. This can be used in conjunction with the existing "cpu group awareness"
in cpufreq infrastructure, to manage the group of CPUs sharing the common 
P-state, in a better way.

The patchset that follows adds this "software-coordination" feature in 
acpi-perflib, and also changes acpi-cpufreq and speedstep-centrino drivers to
use this feature. 

With this feature, current and future platforms (with more than one
logical processor) with Enhanced Speedstep Technology, can use 
software-coordination in place of BIOS(or Hardware)-coordination of P-states. 
The advantages:
1) With software coordination, we can use MSRs to change the frequency, 
instead of using IO ports (as in BIOS coordination). This has a huge advantage
in terms of P-state transition latency. MSR based P-states transition latency 
is around 10uS where as IO port based (which goes through SMM for BIOS 
coordination) latency is around 100uS.
2) Kernel will know about the exact frequency at which each CPU is running. 
With BIOS coordination, actual frequency of a particular CPU may be different
from what kernel thinks it is. As, BIOS changes the frequency of a particular 
CPU depending on last request from the kernel and also the frequency request 
from all the other CPUs in the same domain.

Caveat: BIOSes have to change to to support these new ACPI 3.0 based interfaces.
Not many BIOSes support it today. But, are likely to do it in future, as with 
dual-cores, more number of logical processors share the common P-states.

The patchset also allows "hardware coordination" of P-states among the
CPUs belonging to same P-state dependency domain. Kernel will use either
software or hardware coordination, depending on what BIOS supports on the
particular platform. With hardware coordination among the CPUs of a dependency
domain, we will still have the advantage (2) above, but will not have the 
advantage (1).

Below is more info about each patch in the patchset.

Comments most welcome.
Thanks,
Venki

[PATCH 1/4] Software coordination of freq across CPUs sharing common P-state

Changes to acpi/processor_perflib.c to invoke new (ACPI 3.0) _PSD methods. 
This method has to be called early on all CPUs and P-state dependency domains 
determined before the actual performance_register of P-states.

Also, a new field (shared_type) is added to cpufreq_policy. This is required to support two kinds of CPU groups. One, where one logical CPU can change the 
frequency of all the CPUs by writing into an MSR or IO port. Other, where all 
CPUs in the dependency domain need to write to an MSR or IO port.


[PATCH 2/4] Software coordination of freq across CPUs sharing common P-state

Changes to speedstep-centrino required for supporting cpu groups sharing
common P-state.

acpi_processor_preregister_performance is called initially to determine the
CPU group membership.
centrino_target is chaneg to handle acpu group shared_type of SHARED_TYPE_ANY
and SHARED_TYPE_ALL.


[PATCH 3/4] Software coordination of freq across CPUs sharing common P-state

Changes to acpi-cpufreq required for supporting cpu groups sharing
common P-state

acpi_processor_preregister_performance is called initially to determine the
CPU group membership.
centrino_target is chaneg to handle acpu group shared_type of SHARED_TYPE_ANY
and SHARED_TYPE_ALL.


[PATCH 4/4] Software coordination of freq across CPUs sharing common P-state

Final knob to turn on the P-state cpu groups in acpi-cpufreq and
speedstep-centrino. Add the software coordination bit for _PDC calls.




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

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

* Re: [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state
       [not found] ` <20050831140933.A12497-39QZ/XbsZ5/mO6KZMuUCQVaTQe2KTcn/@public.gmane.org>
@ 2005-09-01  5:29   ` Dave Jones
       [not found]     ` <20050901052903.GA17927-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Dave Jones @ 2005-09-01  5:29 UTC (permalink / raw)
  To: Venkatesh Pallipadi
  Cc: cpufreq, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	Dominik Brodowski, Len Brown, Rajesh Shah

On Wed, Aug 31, 2005 at 02:09:33PM -0700, Venkatesh Pallipadi wrote:

 > ACPI 3.0 (http://www.acpi.info) adds new methods with which BIOS can communicate
 > P-state dependency domains (List of CPUs that share a common P-state) to
 > the OS. This can be used in conjunction with the existing "cpu group awareness"
 > in cpufreq infrastructure, to manage the group of CPUs sharing the common 
 > P-state, in a better way.
 > 
 > The patchset that follows adds this "software-coordination" feature in 
 > acpi-perflib, and also changes acpi-cpufreq and speedstep-centrino drivers to
 > use this feature. 

Patch 1 rejects against the latest git tree, due to Len's latest ACPI changes.
That (and possibly patch 4) need redoing.

>From a first look, these patches look ok to me, so if you rediff these,
and Len is happy with the ACPI changes, I'm happy to merge them for 2.6.14

Thanks,

		Dave



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

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

* Re: [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state
       [not found]     ` <20050901052903.GA17927-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2005-09-01  9:08       ` Dominik Brodowski
  0 siblings, 0 replies; 3+ messages in thread
From: Dominik Brodowski @ 2005-09-01  9:08 UTC (permalink / raw)
  To: Dave Jones
  Cc: Venkatesh Pallipadi, cpufreq,
	acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Len Brown,
	Rajesh Shah

On Thu, Sep 01, 2005 at 01:29:03AM -0400, Dave Jones wrote:
> On Wed, Aug 31, 2005 at 02:09:33PM -0700, Venkatesh Pallipadi wrote:
> 
>  > ACPI 3.0 (http://www.acpi.info) adds new methods with which BIOS can communicate
>  > P-state dependency domains (List of CPUs that share a common P-state) to
>  > the OS. This can be used in conjunction with the existing "cpu group awareness"
>  > in cpufreq infrastructure, to manage the group of CPUs sharing the common 
>  > P-state, in a better way.
>  > 
>  > The patchset that follows adds this "software-coordination" feature in 
>  > acpi-perflib, and also changes acpi-cpufreq and speedstep-centrino drivers to
>  > use this feature. 
> 
> Patch 1 rejects against the latest git tree, due to Len's latest ACPI changes.
> That (and possibly patch 4) need redoing.
> 
> From a first look, these patches look ok to me, so if you rediff these,
> and Len is happy with the ACPI changes, I'm happy to merge them for 2.6.14

Patches

Acked-by: Dominik Brodowski <linux-X3ehHDuj6sIIGcDfoQAp7OTW4wlIGRCZ@public.gmane.org>

Nice work!

	Dominik


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

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

end of thread, other threads:[~2005-09-01  9:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-31 21:09 [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state Venkatesh Pallipadi
     [not found] ` <20050831140933.A12497-39QZ/XbsZ5/mO6KZMuUCQVaTQe2KTcn/@public.gmane.org>
2005-09-01  5:29   ` Dave Jones
     [not found]     ` <20050901052903.GA17927-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2005-09-01  9:08       ` Dominik Brodowski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox