RE: ACPI processor module enhancements

RE: ACPI processor module enhancements

[Brown, Len]

Dominik,
Thanks for the list.
I should probably merge it with the even longer one I have and post it.

Re: ACPI 3.0 features
I think the ACPI 3.0 features will be evolutional.
I'll be most comfortable with new ACPI 3.0 code when
there are systems available to test that we got it right.
I'm not very eager to ship Linux code written to the spec just to
discover
later that the BIOS writers read the spec a different way;
but I know that is a risk we need to take sometimes.

>Hi,
>
>This is meant as sort of a "TODO list" for the ACPI processor 
>module. There are several areas which are in need of improvement -- and

>coordination. To keep in Linux tradition, I've tried to split them up
so that small
>incremental patches are possible:
>
>
>1.) utilize pstate_cnt to notify the BIOS that a P-State 
>driver is present
>This has already been brought up on this list, last in this thread:
>http://marc.theaimsgroup.com/?l=acpi4linux&m=109428989121089&w=2

Do you think we've reached the end of that discussion
and we should put the patch in the release for broader testing?

>2.) support for _CST [more, dynamically configurable CPU power 
>states] on UP
>Patch is at http://bugme.osdl.org/show_bug.cgi?id=1958 -- Bruno's
>"non-dynamic" patch instead of mine is the way to go...

Agreed, this is in the pipeline.

>3.) improved CPU power state selection algorithm
>Some ideas are in my patch 
>http://bugme.osdl.org/show_bug.cgi?id=1958 , it
>needs adaption to TODO#2 and further evaluation, though.

Do you refer to C-states or P-states here?
We have a couple of things we need to fix on C-states.
eg. Bob Moore is testing a patch to fix the bus-master activity part.

>4.) _OSC / _PDC framework
>The _PDC / _OSC methods added in ACPI v. 3.0 are a bit tricky to handle
>because of the modularization in Linux. Basically we need a 
>
>unsigned int acpi_processor_osc_update()
>
>which only adds something to a saved buffer. If the driver 
>requests some
>"control" by calling acpi_processor_osc_update(), the latter 
>should lock the
>driver by "try_module_get()".

We do see _PDC in the field, but I haven't seen _OSC yet.

>5.) _{P,T,C}SD groundwork
>some 
>
>acpi_status acpi_processor_get_domain(..., cpumask_t *cpus, u8 *type);
>
>is needed which a) determines the domain of the CPU passed as argument,
>b) walks through all detected processor objects and looks for 
>the other CPUs
>in this domain [this asserts that all CPUs are initialized as 
>required by
>ACPI spec v.3.0 p.273], c) converts the ACPI CPU numbers to 
>Linux kernel CPU
>numbers, and d) converts this to a cpumask_t

I think we'll only get this right when we can test it on hardware that
supports this.  I expect we'll see that hardware in 2005.

>6.) Utilizing _PSD in the ACPI perflib
>
>The cpufreq core is (almost) ready for handling domains, so 
>it'll be only a
>question of cpufreq driver support for domain ahndling. A helper like
>
>acpi_for_domain_do_fn(cpumask_t domain; (int) (*fn) (unsigned 
>int cpu, cpumask_t allowed_maskm void *), void *data, int type) {
>	int ret = -EINVAL;
>	/* we encourage type ANY as it is faster */
>	if (likely(type == ANY)) { 
>		ret = fn(find_first_bit(domain), domain, data)
>	} else {
>		for_each_cpu_mask(cpu, domain) {
>			ret = fn(cpu, cpu_mask_of_cpu(cpu), data)
>			if (ret)
>				return (ret);
>		}
>	}
>	return (ret);
>}
>
>or something like that may be of assistance here.
>
>
>7.) Support for C2-type sleep on multiprocessor systems.
>
>Already previous versions of the ACPI specification can support that in
>theory, though SMT awareness requires _CSD handling.

I haven't seen any HT or MP systems that support C2.
Maybe those p4-based laptops do?  I agree that MP/MT
support is important.  However, I'm not sure that
software coordination of C-states is mandatory.

>8.) Support for WBINVD-based C3
>
>Only enabled on UP if users explicitely requests it, but 
>always available
>on multiprocessor systems.

IIR Luming was looking into this area.

>9.) throttling support using _PTC/_TSS/_TPC on UP
>Currently only the P_CNT method is available.
>
>
>10.) Make throttling multiprocessor-aware utilizing _TSD
>
>
>11.) [or maybe much much earlier?] split up drivers/acpi/processor.c in
>     individual files and modules:
>	- core
>	- C-States handling
>	- T-States handling
>	- ACPI perflib

I agree with Venki that if this list is prioritized, that this one
should be at the top instead of the bottom -- it doesn't depend
on any new specs or any new hardware.
For a long time I've wanted processor.c to be split up into
separate source files, as different parts have nothing to do
with each other.  (I want "idle" to be in the file name for c-states;-)
I hadn't thought about splitting it into different modules.
On systems with broken c-states and working p-states it would
certainly be handy to be able to unload c-states w/o unloading
p-states...

cheers,
-Len


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: ACPI processor module enhancements

[Dominik Brodowski]

Len,

> Re: ACPI 3.0 features
> I think the ACPI 3.0 features will be evolutional.
> I'll be most comfortable with new ACPI 3.0 code when
> there are systems available to test that we got it right.
> I'm not very eager to ship Linux code written to the spec just to
> discover
> later that the BIOS writers read the spec a different way;
> but I know that is a risk we need to take sometimes.

Agreed, though I'd want to take 3.0 into consideration when deciding on "big
issues" like interfaces and so on.

> >1.) utilize pstate_cnt to notify the BIOS that a P-State 
> >driver is present
> >This has already been brought up on this list, last in this thread:
> >http://marc.theaimsgroup.com/?l=acpi4linux&m=109428989121089&w=2
> 
> Do you think we've reached the end of that discussion
> and we should put the patch in the release for broader testing?

Hm, if you see need for discussion, I'd like to hear about the issues you
see. Otherwise, I'd like it to get broader testing in a month or so when
cpufreq-bk has stabilized again.

> >3.) improved CPU power state selection algorithm
> >Some ideas are in my patch 
> >http://bugme.osdl.org/show_bug.cgi?id=1958 , it
> >needs adaption to TODO#2 and further evaluation, though.
> 
> Do you refer to C-states or P-states here?
C-States

> We have a couple of things we need to fix on C-states.
> eg. Bob Moore is testing a patch to fix the bus-master activity part.

ipw2x00-users will love that. Other than that, I was thinking of a better
algorithm which decides which C-State to implement at a given time. 

> >4.) _OSC / _PDC framework
> >The _PDC / _OSC methods added in ACPI v. 3.0 are a bit tricky to handle
> >because of the modularization in Linux. Basically we need a 
> >
> >unsigned int acpi_processor_osc_update()
> >
> >which only adds something to a saved buffer. If the driver 
> >requests some
> >"control" by calling acpi_processor_osc_update(), the latter 
> >should lock the
> >driver by "try_module_get()".
> 
> We do see _PDC in the field, but I haven't seen _OSC yet.

Well, if we do support CPU domain awareness in C- and T-States as well, we
need some sort of coordination for _PDC == _OSC. And as _OSC seems to be the
way to go in future, I'd name it after OSC and already provide capability
for _OSC.

> >5.) _{P,T,C}SD groundwork
> >some 
> >
> >acpi_status acpi_processor_get_domain(..., cpumask_t *cpus, u8 *type);
> >
> >is needed which a) determines the domain of the CPU passed as argument,
> >b) walks through all detected processor objects and looks for 
> >the other CPUs
> >in this domain [this asserts that all CPUs are initialized as 
> >required by
> >ACPI spec v.3.0 p.273], c) converts the ACPI CPU numbers to 
> >Linux kernel CPU
> >numbers, and d) converts this to a cpumask_t
> 
> I think we'll only get this right when we can test it on hardware that
> supports this.  I expect we'll see that hardware in 2005.

-> delayed.

> >7.) Support for C2-type sleep on multiprocessor systems.
> >
> >Already previous versions of the ACPI specification can support that in
> >theory, though SMT awareness requires _CSD handling.
> 
> I haven't seen any HT or MP systems that support C2.
> Maybe those p4-based laptops do?  I agree that MP/MT
> support is important.  However, I'm not sure that
> software coordination of C-states is mandatory.

It's definitely something necessary for those dual-core Pentium Ms which
have been announced by Intel.

> >8.) Support for WBINVD-based C3
> >
> >Only enabled on UP if users explicitely requests it, but 
> >always available
> >on multiprocessor systems.
> 
> IIR Luming was looking into this area.

Excellent.

> >11.) [or maybe much much earlier?] split up drivers/acpi/processor.c in
> >     individual files and modules:
> >	- core
> >	- C-States handling
> >	- T-States handling
> >	- ACPI perflib
> 
> I agree with Venki that if this list is prioritized, that this one
> should be at the top instead of the bottom -- it doesn't depend
> on any new specs or any new hardware.
> For a long time I've wanted processor.c to be split up into
> separate source files, as different parts have nothing to do
> with each other.  (I want "idle" to be in the file name for c-states;-)
> I hadn't thought about splitting it into different modules.
> On systems with broken c-states and working p-states it would
> certainly be handy to be able to unload c-states w/o unloading
> p-states...

... but splitting it up in source files as a first step would be much
easier. I'll prepare a patch which does exactly that over the weekend. Then
it'll be easier and cleaner to handle this large list of updates and issues;
though some patches will break in between...

Thanks,
	Dominik


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: ACPI processor module enhancements

[Len Brown]

On Fri, 2004-10-08 at 16:26, Dominik Brodowski wrote:
> Len,
> 
> > Re: ACPI 3.0 features
> > I think the ACPI 3.0 features will be evolutional.
> > I'll be most comfortable with new ACPI 3.0 code when
> > there are systems available to test that we got it right.
> > I'm not very eager to ship Linux code written to the spec just to
> > discover
> > later that the BIOS writers read the spec a different way;
> > but I know that is a risk we need to take sometimes.
> 
> Agreed, though I'd want to take 3.0 into consideration when deciding
> on "big issues" like interfaces and so on.

Right.

> > >1.) utilize pstate_cnt to notify the BIOS that a P-State
> > >driver is present
> > >This has already been brought up on this list, last in this thread:
> > >http://marc.theaimsgroup.com/?l=acpi4linux&m=109428989121089&w=2
> >
> > Do you think we've reached the end of that discussion
> > and we should put the patch in the release for broader testing?
> 
> Hm, if you see need for discussion, I'd like to hear about the issues
> you see. Otherwise, I'd like it to get broader testing in a month or
> so when cpufreq-bk has stabilized again.

okay, i've put it into my acpi-mm tree where andrew will pick it up.
if no problems, later it will go into 2.6.10.

> > >3.) improved CPU power state selection algorithm
> > >Some ideas are in my patch
> > >http://bugme.osdl.org/show_bug.cgi?id=1958 , it
> > >needs adaption to TODO#2 and further evaluation, though.
> >
> > Do you refer to C-states or P-states here?
> C-States
> 
> > We have a couple of things we need to fix on C-states.
> > eg. Bob Moore is testing a patch to fix the bus-master activity
> part.
> 
> ipw2x00-users will love that. Other than that, I was thinking of a
> better algorithm which decides which C-State to implement at a given
> time.

yes, i expect we should use an algorithm that accounts for how busy the
system is, not just how idle it was.

> > >4.) _OSC / _PDC framework
> > >The _PDC / _OSC methods added in ACPI v. 3.0 are a bit tricky to
> handle
> > >because of the modularization in Linux. Basically we need a
> > >
> > >unsigned int acpi_processor_osc_update()
> > >
> > >which only adds something to a saved buffer. If the driver
> > >requests some
> > >"control" by calling acpi_processor_osc_update(), the latter
> > >should lock the
> > >driver by "try_module_get()".
> >
> > We do see _PDC in the field, but I haven't seen _OSC yet.
> 
> Well, if we do support CPU domain awareness in C- and T-States as
> well, we need some sort of coordination for _PDC == _OSC. And as _OSC
> seems to be the way to go in future, I'd name it after OSC and already
> provide capability for _OSC.
> 
> > >5.) _{P,T,C}SD groundwork
> > >some
> > >
> > >acpi_status acpi_processor_get_domain(..., cpumask_t *cpus, u8
> *type);
> > >
> > >is needed which a) determines the domain of the CPU passed as
> argument,
> > >b) walks through all detected processor objects and looks for
> > >the other CPUs
> > >in this domain [this asserts that all CPUs are initialized as
> > >required by
> > >ACPI spec v.3.0 p.273], c) converts the ACPI CPU numbers to
> > >Linux kernel CPU
> > >numbers, and d) converts this to a cpumask_t
> >
> > I think we'll only get this right when we can test it on hardware
> that
> > supports this.  I expect we'll see that hardware in 2005.
> 
> -> delayed.
> 
> > >7.) Support for C2-type sleep on multiprocessor systems.
> > >
> > >Already previous versions of the ACPI specification can support
> that in
> > >theory, though SMT awareness requires _CSD handling.
> >
> > I haven't seen any HT or MP systems that support C2.
> > Maybe those p4-based laptops do?  I agree that MP/MT
> > support is important.  However, I'm not sure that
> > software coordination of C-states is mandatory.
> 
> It's definitely something necessary for those dual-core Pentium Ms
> which have been announced by Intel.

I expect we'll do dual-core internally b/c we'll be able to get the
hardware before it is available on the market.

If anybody sees an HT-capable system that supports C2 in the mean-time,
I'd be interested to know about it.

> > >8.) Support for WBINVD-based C3
> > >
> > >Only enabled on UP if users explicitely requests it, but
> > >always available
> > >on multiprocessor systems.
> >
> > IIR Luming was looking into this area.
> 
> Excellent.
> 
> > >11.) [or maybe much much earlier?] split up
> drivers/acpi/processor.c in
> > >     individual files and modules:
> > >     - core
> > >     - C-States handling
> > >     - T-States handling
> > >     - ACPI perflib
> >
> > I agree with Venki that if this list is prioritized, that this one
> > should be at the top instead of the bottom -- it doesn't depend
> > on any new specs or any new hardware.
> > For a long time I've wanted processor.c to be split up into
> > separate source files, as different parts have nothing to do
> > with each other.  (I want "idle" to be in the file name for
> c-states;-)
> > I hadn't thought about splitting it into different modules.
> > On systems with broken c-states and working p-states it would
> > certainly be handy to be able to unload c-states w/o unloading
> > p-states...
> 
> ... but splitting it up in source files as a first step would be much
> easier. I'll prepare a patch which does exactly that over the weekend.
> Then it'll be easier and cleaner to handle this large list of updates
> and issues; though some patches will break in between...

great!

thanks,
-Len




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: RE: ACPI processor module enhancements

[Pavel Machek]

Hi!

> Re: ACPI 3.0 features
> I think the ACPI 3.0 features will be evolutional.
> I'll be most comfortable with new ACPI 3.0 code when
> there are systems available to test that we got it right.
> I'm not very eager to ship Linux code written to the spec just to
> discover
> later that the BIOS writers read the spec a different way;
> but I know that is a risk we need to take sometimes.

Well, at least BIOS writers will have something to test against. If we
do not have any support for ACPI3, they will just test windows on
prototypes...
								Pavel



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: ACPI processor module enhancements

[Dominik Brodowski]

> The patch is simple, And I haven't started to eliminate " "C3 not
> supported in SMP mode".

There's a check for

((acpi_fadt.wb_invd) && (!acpi_fadt.wb_invd_flush))) 

missing, and I think the latency (as that is decisive on what C-State is
entered) should be increased if FLUSH_CACHE is used. For example like I did
in my example implementation in 2002 ;-)

Thanks,
	Dominik


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

RE: ACPI processor module enhancements

[Yu, Luming]

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

>
>> >8.) Support for WBINVD-based C3
>> >
>> >Only enabled on UP if users explicitely requests it, but 
>> >always available
>> >on multiprocessor systems.
>> 
>> IIR Luming was looking into this area.

I recall I have ever made a patch to remove:

               else if (!pr->flags.bm_control)
                       ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                               "C3 support requires bus mastering
control\n"));

The patch is simple, And I haven't started to eliminate " "C3 not
supported in SMP mode".

Thanks,
Luming

diff -Bru 2.6.new/drivers/acpi/processor.c
patched/drivers/acpi/processor.c
--- 2.6.new/drivers/acpi/processor.c    2004-04-28 11:45:02.000000000
+0800
+++ patched/drivers/acpi/processor.c    2004-05-26 14:38:05.000000000
+0800
@@ -428,8 +428,12 @@
                break;

        case ACPI_STATE_C3:
-               /* Disable bus master arbitration */
-               acpi_set_register(ACPI_BITREG_ARB_DISABLE, 1,
ACPI_MTX_DO_NOT_LOCK);
+
+               if(pr->flags.bm_control)
+                       acpi_set_register(ACPI_BITREG_ARB_DISABLE, 1,
ACPI_MTX_DO_NOT_LOCK); /* Disable bus master arbitration */
+               else
+                       ACPI_FLUSH_CPU_CACHE ();
+
                /* Get start time (ticks) */
                t1 = inl(acpi_fadt.xpm_tmr_blk.address);
                /* Invoke C3 */
@@ -438,8 +442,10 @@
                t2 = inl(acpi_fadt.xpm_tmr_blk.address);
                /* Get end time (ticks) */
                t2 = inl(acpi_fadt.xpm_tmr_blk.address);
-               /* Enable bus master arbitration */
-               acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0,
ACPI_MTX_DO_NOT_LOCK);
+
+               if(pr->flags.bm_control)
+                       acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0,
ACPI_MTX_DO_NOT_LOCK); /* Enable bus master arbitration */
+
                /* Re-enable interrupts */
                local_irq_enable();
                /* Compute time (ticks) that we were actually asleep */
@@ -676,14 +682,7 @@
                        ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                                "C3 latency too large [%d]\n",
                                acpi_fadt.plvl3_lat));
-               /*
-                * Only support C3 when bus mastering arbitration
control
-                * is present (able to disable bus mastering to maintain
-                * cache coherency while in C3).
-                */
-               else if (!pr->flags.bm_control)
-                       ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-                               "C3 support requires bus mastering
control\n"));
+
                /*
                 * Only support C3 on UP systems, as bm_control is only
viable
                 * on a UP system and flushing caches (e.g. WBINVD) is
simply

[-- Attachment #2: c3_wbinvd.patch --]
[-- Type: application/octet-stream, Size: 1723 bytes --]

diff -Bru 2.6.new/drivers/acpi/processor.c patched/drivers/acpi/processor.c
--- 2.6.new/drivers/acpi/processor.c	2004-04-28 11:45:02.000000000 +0800
+++ patched/drivers/acpi/processor.c	2004-05-26 14:38:05.000000000 +0800
@@ -428,8 +428,12 @@
 		break;
 
 	case ACPI_STATE_C3:
-		/* Disable bus master arbitration */
-		acpi_set_register(ACPI_BITREG_ARB_DISABLE, 1, ACPI_MTX_DO_NOT_LOCK);
+
+		if(pr->flags.bm_control)
+			acpi_set_register(ACPI_BITREG_ARB_DISABLE, 1, ACPI_MTX_DO_NOT_LOCK); /* Disable bus master arbitration */
+		else
+			ACPI_FLUSH_CPU_CACHE ();
+
 		/* Get start time (ticks) */
 		t1 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Invoke C3 */
@@ -438,8 +442,10 @@
 		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Get end time (ticks) */
 		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
-		/* Enable bus master arbitration */
-		acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_DO_NOT_LOCK);
+
+		if(pr->flags.bm_control)
+			acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_DO_NOT_LOCK); /* Enable bus master arbitration */
+
 		/* Re-enable interrupts */
 		local_irq_enable();
 		/* Compute time (ticks) that we were actually asleep */
@@ -676,14 +682,7 @@
 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 				"C3 latency too large [%d]\n", 
 				acpi_fadt.plvl3_lat));
-		/*
-		 * Only support C3 when bus mastering arbitration control
-		 * is present (able to disable bus mastering to maintain
-		 * cache coherency while in C3).
-		 */
-		else if (!pr->flags.bm_control)
-			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-				"C3 support requires bus mastering control\n"));
+
 		/*
 		 * Only support C3 on UP systems, as bm_control is only viable
 		 * on a UP system and flushing caches (e.g. WBINVD) is simply 

ACPI processor module enhancements

[Dominik Brodowski]

Hi,

This is meant as sort of a "TODO list" for the ACPI processor module. There
are several areas which are in need of improvement -- and coordination. To
keep in Linux tradition, I've tried to split them up so that small
incremental patches are possible:


1.) utilize pstate_cnt to notify the BIOS that a P-State driver is present
This has already been brought up on this list, last in this thread:
http://marc.theaimsgroup.com/?l=acpi4linux&m=109428989121089&w=2


2.) support for _CST [more, dynamically configurable CPU power states] on UP
Patch is at http://bugme.osdl.org/show_bug.cgi?id=1958 -- Bruno's
"non-dynamic" patch instead of mine is the way to go...


3.) improved CPU power state selection algorithm
Some ideas are in my patch http://bugme.osdl.org/show_bug.cgi?id=1958 , it
needs adaption to TODO#2 and further evaluation, though.


4.) _OSC / _PDC framework
The _PDC / _OSC methods added in ACPI v. 3.0 are a bit tricky to handle
because of the modularization in Linux. Basically we need a 

unsigned int acpi_processor_osc_update()

which only adds something to a saved buffer. If the driver requests some
"control" by calling acpi_processor_osc_update(), the latter should lock the
driver by "try_module_get()".


5.) _{P,T,C}SD groundwork
some 

acpi_status acpi_processor_get_domain(..., cpumask_t *cpus, u8 *type);

is needed which a) determines the domain of the CPU passed as argument,
b) walks through all detected processor objects and looks for the other CPUs
in this domain [this asserts that all CPUs are initialized as required by
ACPI spec v.3.0 p.273], c) converts the ACPI CPU numbers to Linux kernel CPU
numbers, and d) converts this to a cpumask_t


6.) Utilizing _PSD in the ACPI perflib

The cpufreq core is (almost) ready for handling domains, so it'll be only a
question of cpufreq driver support for domain ahndling. A helper like

acpi_for_domain_do_fn(cpumask_t domain; (int) (*fn) (unsigned int cpu, cpumask_t allowed_maskm void *), void *data, int type) {
	int ret = -EINVAL;
	/* we encourage type ANY as it is faster */
	if (likely(type == ANY)) { 
		ret = fn(find_first_bit(domain), domain, data)
	} else {
		for_each_cpu_mask(cpu, domain) {
			ret = fn(cpu, cpu_mask_of_cpu(cpu), data)
			if (ret)
				return (ret);
		}
	}
	return (ret);
}

or something like that may be of assistance here.


7.) Support for C2-type sleep on multiprocessor systems.

Already previous versions of the ACPI specification can support that in
theory, though SMT awareness requires _CSD handling.


8.) Support for WBINVD-based C3

Only enabled on UP if users explicitely requests it, but always available
on multiprocessor systems.


9.) throttling support using _PTC/_TSS/_TPC on UP
Currently only the P_CNT method is available.


10.) Make throttling multiprocessor-aware utilizing _TSD


11.) [or maybe much much earlier?] split up drivers/acpi/processor.c in
     individual files and modules:
	- core
	- C-States handling
	- T-States handling
	- ACPI perflib


	Dominik


-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m