headers
Dave Jones | 1 Sep 2005 07:29
Picon
Favicon

Re: [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state

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 | Reply | 0 comments |
headers
Dominik Brodowski | 1 Sep 2005 11:08

Re: [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state

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

Nice work!

	Dominik

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pallipadi, Venkatesh | 1 Sep 2005 20:04
Picon
Favicon

RE: Re: [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state


>-----Original Message-----
>From: acpi-devel-admin@... 
>[mailto:acpi-devel-admin@...] On Behalf Of 
>Dominik Brodowski
>Sent: Thursday, September 01, 2005 2:08 AM
>To: Dave Jones
>Cc: Pallipadi, Venkatesh; cpufreq; 
>acpi-devel@...; Brown, Len; Shah, Rajesh
>Subject: [ACPI] Re: [RFC][PATCH 0/4] Software coordination of 
>frequency across CPUs sharing common P-state
>
>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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Jones | 1 Sep 2005 21:31
Picon
Favicon

Re: Re: [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state

On Thu, Sep 01, 2005 at 03:20:33PM -0400, Brown, Len wrote:
 >  
 > >I had rebased my patch over Len's acpi-20050815-2.6.13 . Probably 
 > >some part of it is still not in git that is causing the conflict. 
 > >I will rebase the patch with latest git, before I resend the patch.
 > 
 > FYI we're planning to send this ACPI patch to Linus in the next
 > few days.  It includes a huge Lindent flag-day, so we really
 > want to get it into 2.6.14 extremely early, but we need to
 > button up a few things first.

Ok, given Linus seems to now be away (for a week?) this gives a
bit of time for Venkatesh to get his bits in shape before you
do your merge.  It should all just work out in time :)

		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 | Reply | 0 comments |
headers
Brown, Len | 1 Sep 2005 21:20
Picon
Favicon
Gravatar

RE: Re: [RFC][PATCH 0/4] Software coordination of frequency across CPUs sharing common P-state


>I had rebased my patch over Len's acpi-20050815-2.6.13 . Probably 
>some part of it is still not in git that is causing the conflict. 
>I will rebase the patch with latest git, before I resend the patch.

FYI we're planning to send this ACPI patch to Linus in the next
few days.  It includes a huge Lindent flag-day, so we really
want to get it into 2.6.14 extremely early, but we need to
button up a few things first.

-Len

-------------------------------------------------------
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 | Reply | 2 comments |
headers
Andrew Morton | 3 Sep 2005 02:24

Re: [x86_64] Exception when using powernowd.

Kyuma Ohta <whatisthis <at> jcom.home.ne.jp> wrote:
>
> I'm using MSI K8T Neo2 (VIA K8T800 chipset) and Athlon64 3000+
> with  linux x86_64 2.6.13 kernel and Debian/sid.
> When enable powernow-k8 (i.e. using powernowd,cpudyn) to
> saving power, some process is down by null protection and
> system is unstable.
> Then disabling powernow-k8,and reboot, system is very stable.
> 
> I attach any log,please give me a advice.

Did earlier kernels work OK?  Can you identify the most recent 2.6 kernel
which didn't have this bug?
Permalink | Reply | 0 comments |
headers
Kyuma Ohta | 3 Sep 2005 03:52
Picon

Re: [x86_64] Exception when using powernowd.

Thanx,Andrew,

Written by Andrew Morton <akpm <at> osdl.org>
   at Fri, 2 Sep 2005 17:24:37 -0700 :
Subject: Re: [x86_64] Exception when using powernowd.

akpm> Kyuma Ohta <whatisthis <at> jcom.home.ne.jp> wrote:
akpm> >
akpm> > I'm using MSI K8T Neo2 (VIA K8T800 chipset) and Athlon64 3000+
akpm> > with  linux x86_64 2.6.13 kernel and Debian/sid.
akpm> > When enable powernow-k8 (i.e. using powernowd,cpudyn) to
akpm> > saving power, some process is down by null protection and
akpm> > system is unstable.
akpm> > Then disabling powernow-k8,and reboot, system is very stable.
akpm> > 
akpm> > I attach any log,please give me a advice.
akpm> 
akpm> Did earlier kernels work OK?  Can you identify the most recent 2.6 kernel
akpm> which didn't have this bug?

 Without powernow! feature, works fine.(I tested every -rc kernel 
after 2.6.8 for x86_64).
 With powernow! feature,works bad at least after 2.6.11-rc*.

 I'm using xserver-xorg at debian,6.8.2-dfsg.1-5 happend OOPS 
at any process using X any older kernel, but update X to 6.8.2-6,
any processes not/with using  X got  null exception and down
when enable powernow! feature :-(
 What happened?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkatesh Pallipadi | 14 Sep 2005 01:57
Picon
Favicon

[ACPI][PATCH 0/4] (take 2) Software coordination of frequency across CPUs sharing common P-state


Take 2 of patchset posted earlier (Sub -
"Software coordination of frequency across CPUs sharing common P-state")

Changes since last post:
- Small changes to make things work with CPU_HOTPLUG
- Minor changes and cleanups

Outstanding issue:
- "affected_cpus" unaware userlevel policies can change CPU frequencies wrongly.
If the userlevel policy is unaware that CPU freqs can be shared across CPUs,
and assumes each CPU has independent control, then it can change the frequencies
wrongly. 

Say CPU 0 and CPU 1 share a P-state. That information is exposed 
by kernel. But, if userspace daemon doesn't know about it (legacy daemon),
then it thinks each CPU is independent, and whenever one CPu (say CPU 1) is
idle it lowers CPU 1's frequency. And even when CPU 0 is busy, CPU 0's frequency
will get reduced in such a circumstance. And all this can happen silently,
letting the user to wonder why performance has gone down.

I don't know of any clean way of providing backward compatibility to those
(legacy) userlevel policy. Keeping this patch in mm for a while (until 2.6.14)
should provide a chance to identify such userlevel policies and fix them.

(Rest of this mail is same as in original thread)

Details:

ACPI 3.0 (http://www.acpi.info) adds new methods with which BIOS can communicate
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkatesh Pallipadi | 14 Sep 2005 02:01
Picon
Favicon

[ACPI][PATCH 1/4] (take 2) Software coordination of freq across CPUs sharing common P-state


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

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...>

Index: linux-2.6.12/drivers/acpi/processor_perflib.c
===================================================================
--- linux-2.6.12.orig/drivers/acpi/processor_perflib.c	2005-08-31 14:46:39.311563456 -0700
+++ linux-2.6.12/drivers/acpi/processor_perflib.c	2005-09-06 15:44:19.707724344 -0700
 <at>  <at>  -304,6 +304,85  <at>  <at> 
 	return_VALUE(result);
 }

+static int acpi_processor_get_psd(struct acpi_processor	*pr)
+{
+	int result = 0;
+	acpi_status status = AE_OK;
+	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+	struct acpi_buffer format = {sizeof("NNNNN"), "NNNNN"};
+	struct acpi_buffer state = {0, NULL};
+	union acpi_object  *psd = NULL;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkatesh Pallipadi | 14 Sep 2005 02:03
Picon
Favicon

[ACPI][PATCH 3/4] (take 2) Software coordination of freq across CPUs sharing common P-state


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

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...>

Index: linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===================================================================
--- linux-2.6.12.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	2005-09-06
09:44:19.924390528 -0700
+++ linux-2.6.12/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	2005-09-06 13:39:11.391161960 -0700
 <at>  <at>  -49,12 +49,13  <at>  <at> 

 
 struct cpufreq_acpi_io {
-	struct acpi_processor_performance	acpi_data;
+	struct acpi_processor_performance	*acpi_data;
 	struct cpufreq_frequency_table		*freq_table;
 	unsigned int				resume;
 };

 static struct cpufreq_acpi_io	*acpi_io_data[NR_CPUS];
+static struct acpi_processor_performance	*acpi_perf_data[NR_CPUS];
(Continue reading)

Permalink | Reply | 0 comments |

Gmane