[PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Dasgupta, Romit]

(Tested on Zoom2).

'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
struct device *. This is a problem because invoking these functions from
different clients would result in setting of the resource level as requested by
the last caller. Fixes this by introducing a struct device * to the parameter
list for these functions.
Signed-off-by: Romit Dasgupta <romit@ti.com>
---

diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 8e67861..e9adc67 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -47,6 +47,7 @@ static struct cpufreq_frequency_table *freq_table;
 #define MPU_CLK		"virt_prcm_set"
 #endif
 
+DEFINE_PER_CPU(struct device , cpu_freq_dev);
 static struct clk *mpu_clk;
 
 /* TODO: Add support for SDRAM timing changes */
@@ -115,8 +116,9 @@ static int omap_target(struct cpufreq_policy *policy,
 		int ind;
 		for (ind = 1; ind <= MAX_VDD1_OPP; ind++) {
 			if (mpu_opps[ind].rate/1000 >= target_freq) {
-				omap_pm_cpu_set_freq
-					(mpu_opps[ind].rate);
+				omap_pm_cpu_set_freq(
+					&__get_cpu_var(cpu_freq_dev),
+					mpu_opps[ind].rate);
 				break;
 			}
 		}
diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h b/arch/arm/plat-omap/include/mach/omap-pm.h
index 583e540..5b26ba1 100644
--- a/arch/arm/plat-omap/include/mach/omap-pm.h
+++ b/arch/arm/plat-omap/include/mach/omap-pm.h
@@ -226,6 +226,7 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void);
 
 /**
  * omap_pm_dsp_set_min_opp - receive desired OPP target ID from DSP Bridge
+ * @dev: Identifies the client that wants to set the VDD1 OPP.
  * @opp_id: target DSP OPP ID
  *
  * Set a minimum OPP ID for the DSP.  This is intended to be called
@@ -233,7 +234,7 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void);
  * information that code receives from the DSP/BIOS load estimator is the
  * target OPP ID; hence, this interface.  No return value.
  */
-void omap_pm_dsp_set_min_opp(u8 opp_id);
+void omap_pm_dsp_set_min_opp(struct device *dev, u8 opp_id);
 
 /**
  * omap_pm_dsp_get_opp - report the current DSP OPP ID
@@ -283,6 +284,7 @@ struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table(void);
 
 /**
  * omap_pm_cpu_set_freq - set the current minimum MPU frequency
+ * @dev: Identifies the client that wants to set the frequency.
  * @f: MPU frequency in Hz
  *
  * Set the current minimum CPU frequency.  The actual CPU frequency
@@ -290,7 +292,7 @@ struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table(void);
  * Intended to be called by plat-omap/cpu_omap.c:omap_target().  No
  * return value.
  */
-void omap_pm_cpu_set_freq(unsigned long f);
+void omap_pm_cpu_set_freq(struct device *dev, unsigned long f);
 
 /**
  * omap_pm_cpu_get_freq - report the current CPU frequency
diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-noop.c
index 10463a4..6546527 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -159,7 +159,7 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void)
 }
 EXPORT_SYMBOL(omap_pm_dsp_get_opp_table);
 
-void omap_pm_dsp_set_min_opp(u8 opp_id)
+void omap_pm_dsp_set_min_opp(struct device *dev, u8 opp_id)
 {
 	if (opp_id == 0) {
 		WARN_ON(1);
@@ -244,7 +244,7 @@ struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table(void)
 	return NULL;
 }
 
-void omap_pm_cpu_set_freq(unsigned long f)
+void omap_pm_cpu_set_freq(struct device *dev, unsigned long f)
 {
 	if (f == 0) {
 		WARN_ON(1);
diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c
index 4350650..aece740 100644
--- a/arch/arm/plat-omap/omap-pm-srf.c
+++ b/arch/arm/plat-omap/omap-pm-srf.c
@@ -169,8 +169,6 @@ void omap_pm_set_max_sdma_lat(struct device *dev, long t)
 	}
 }
 
-static struct device dummy_dsp_dev;
-
 /*
  * DSP Bridge-specific constraints
  */
@@ -187,20 +185,15 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void)
 }
 EXPORT_SYMBOL(omap_pm_dsp_get_opp_table);
 
-void omap_pm_dsp_set_min_opp(u8 opp_id)
+void omap_pm_dsp_set_min_opp(struct device *dev, u8 opp_id)
 {
-	if (opp_id == 0) {
+	if (dev == NULL || opp_id == 0) {
 		WARN_ON(1);
 		return;
 	}
 
 	pr_debug("OMAP PM: DSP requests minimum VDD1 OPP to be %d\n", opp_id);
-
-	/*
-	 * For now pass a dummy_dev struct for SRF to identify the caller.
-	 * Maybe its good to have DSP pass this as an argument
-	 */
-	resource_request("vdd1_opp", &dummy_dsp_dev, opp_id);
+	resource_request("vdd1_opp", dev, opp_id);
 	return;
 }
 EXPORT_SYMBOL(omap_pm_dsp_set_min_opp);
@@ -246,19 +239,16 @@ struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table(void)
 	return NULL;
 }
 
-static struct device dummy_cpufreq_dev;
-
-void omap_pm_cpu_set_freq(unsigned long f)
+void omap_pm_cpu_set_freq(struct device *dev, unsigned long f)
 {
-	if (f == 0) {
+	if (dev == NULL || f == 0) {
 		WARN_ON(1);
 		return;
 	}
 
 	pr_debug("OMAP PM: CPUFreq requests CPU frequency to be set to %lu\n",
 		 f);
-
-	resource_request("mpu_freq", &dummy_cpufreq_dev, f);
+	resource_request("mpu_freq", dev, f);
 	return;
 }
 EXPORT_SYMBOL(omap_pm_cpu_set_freq);

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Kevin Hilman]

"Dasgupta, Romit" <romit@ti.com> writes:

> (Tested on Zoom2).
>
> 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
> struct device *. This is a problem because invoking these functions from
> different clients would result in setting of the resource level as requested by
> the last caller. Fixes this by introducing a struct device * to the parameter
> list for these functions.
> Signed-off-by: Romit Dasgupta <romit@ti.com>


This looks like the right fix to me.

Paul, any comments?

Kevin

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Paul Walmsley]

On Tue, 13 Oct 2009, Kevin Hilman wrote:

> "Dasgupta, Romit" <romit@ti.com> writes:
> 
> > (Tested on Zoom2).
> >
> > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
> > struct device *. This is a problem because invoking these functions from
> > different clients would result in setting of the resource level as requested by
> > the last caller. Fixes this by introducing a struct device * to the parameter
> > list for these functions.
> > Signed-off-by: Romit Dasgupta <romit@ti.com>
> 
> 
> This looks like the right fix to me.
> 
> Paul, any comments?

Acked-by: Paul Walmsley <paul@pwsan.com>


- Paul

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Paul Walmsley]

On Tue, 13 Oct 2009, Kevin Hilman wrote:

> "Dasgupta, Romit" <romit@ti.com> writes:
> 
> > (Tested on Zoom2).
> >
> > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
> > struct device *. This is a problem because invoking these functions from
> > different clients would result in setting of the resource level as requested by
> > the last caller. Fixes this by introducing a struct device * to the parameter
> > list for these functions.
> > Signed-off-by: Romit Dasgupta <romit@ti.com>
> 
> 
> This looks like the right fix to me.
> 
> Paul, any comments?


Wait a minute, I am retracting my ack.


Romit, the only caller of omap_pm_dsp_set_min_opp() should be DSPBridge 
and the only caller of omap_pm_cpu_set_freq() should be CPUFreq.  So the 
struct device * pointer is not necessary, unless I am missing something.  
Can you please explain what you're trying to do?



- Paul

RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Madhusudhan]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Wednesday, October 28, 2009 1:38 PM
> To: Kevin Hilman
> Cc: Dasgupta\, Romit; linux-omap\@vger.kernel.org
> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
> 
> On Tue, 13 Oct 2009, Kevin Hilman wrote:
> 
> > "Dasgupta, Romit" <romit@ti.com> writes:
> >
> > > (Tested on Zoom2).
> > >
> > > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their
> own
> > > struct device *. This is a problem because invoking these functions
> from
> > > different clients would result in setting of the resource level as
> requested by
> > > the last caller. Fixes this by introducing a struct device * to the
> parameter
> > > list for these functions.
> > > Signed-off-by: Romit Dasgupta <romit@ti.com>
> >
> >
> > This looks like the right fix to me.
> >
> > Paul, any comments?
> 
> 
> Wait a minute, I am retracting my ack.
> 
> 
> Romit, the only caller of omap_pm_dsp_set_min_opp() should be DSPBridge
> and the only caller of omap_pm_cpu_set_freq() should be CPUFreq.  So the
> struct device * pointer is not necessary, unless I am missing something.
> Can you please explain what you're trying to do?
> 
I believe that omap_pm_cpu_set_freq() can be called by drivers to setup the
optimal vdd1 opp, right? For example MMC works at opp1 but the performance
is certainly better at opp3.When ondemand is enabled drivers need to put
certain constraints on vdd1 opp otherwise performance will be hurt. So, if
the API takes care of device level calls then drivers can call this fn.

Regards,
Madhu
> 
> 
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Kevin Hilman]

"Madhusudhan" <madhu.cr@ti.com> writes:

>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Paul Walmsley
>> Sent: Wednesday, October 28, 2009 1:38 PM
>> To: Kevin Hilman
>> Cc: Dasgupta\, Romit; linux-omap\@vger.kernel.org
>> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
>> framework functions
>> 
>> On Tue, 13 Oct 2009, Kevin Hilman wrote:
>> 
>> > "Dasgupta, Romit" <romit@ti.com> writes:
>> >
>> > > (Tested on Zoom2).
>> > >
>> > > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their
>> own
>> > > struct device *. This is a problem because invoking these functions
>> from
>> > > different clients would result in setting of the resource level as
>> requested by
>> > > the last caller. Fixes this by introducing a struct device * to the
>> parameter
>> > > list for these functions.
>> > > Signed-off-by: Romit Dasgupta <romit@ti.com>
>> >
>> >
>> > This looks like the right fix to me.
>> >
>> > Paul, any comments?
>> 
>> 
>> Wait a minute, I am retracting my ack.
>> 
>> 
>> Romit, the only caller of omap_pm_dsp_set_min_opp() should be DSPBridge
>> and the only caller of omap_pm_cpu_set_freq() should be CPUFreq.  So the
>> struct device * pointer is not necessary, unless I am missing something.
>> Can you please explain what you're trying to do?
>> 
> I believe that omap_pm_cpu_set_freq() can be called by drivers to setup the
> optimal vdd1 opp, right? For example MMC works at opp1 but the performance
> is certainly better at opp3.When ondemand is enabled drivers need to put
> certain constraints on vdd1 opp otherwise performance will be hurt. So, if
> the API takes care of device level calls then drivers can call this fn.

So, the root use case is a power vs. performance policy decision.  And
using the proposed solution, a single driver gets to make a system
wide policy decision.  I don't like this.

For your MMC usecase, I think we need some clarifications.

What exactly does "better" performance mean.  Is it better throughput
that is needed?  or is it really the MPU side that is not
running/responding fast enough.

If it's throughput, then omap_pm_set_min_bus_tput() should be used.

If it's the MPU, what exactly is the problem with ondemand.  Is it
that it doesn't respond fast enough?  Or that it never switches to a
higher OPP.

Kevin

RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Dasgupta, Romit]

Paul/Kevin,
                      As Madhu explained it looks like there are instances where we forcibly need to bump up to a higher CPU + L3 frequencies (VDD1 + VDD2 scaling). I understand that this should be done by cpufreq governors but here is reason that I think the current cpufreq governors won't be able to handle.

Large latency response:
      
     The sampling intervals for the cpufreq governors are quite large and thus the latency for the frequency change to occur is large. This was seen in Android UI responsiveness. The initial response of the UI seems to be quite sluggish until after a while when the cpufreq governors would catch up to the required MIPS.  I know that Patrick (Cc'd) did some experiments with conservative governor but my understanding is that it still has this basic problem.

Tied to the above is necessity for high MIPS for short duration:

I also presume that there might be situations where we need very high MIPS but for a very very short interval of time. This would never bump up the frequency as it would more or less be ignored by the cpufreq governors.

Please let me know what you think.
Thanks,
-Romit


> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, October 29, 2009 4:15 AM
> To: Chikkature Rajashekar, Madhusudhan
> Cc: 'Paul Walmsley'; Dasgupta, Romit; 'linux-omap@vger.kernel.org'
> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
> 
> "Madhusudhan" <madhu.cr@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of Paul Walmsley
> >> Sent: Wednesday, October 28, 2009 1:38 PM
> >> To: Kevin Hilman
> >> Cc: Dasgupta\, Romit; linux-omap\@vger.kernel.org
> >> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> >> framework functions
> >>
> >> On Tue, 13 Oct 2009, Kevin Hilman wrote:
> >>
> >> > "Dasgupta, Romit" <romit@ti.com> writes:
> >> >
> >> > > (Tested on Zoom2).
> >> > >
> >> > > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using
> their
> >> own
> >> > > struct device *. This is a problem because invoking these functions
> >> from
> >> > > different clients would result in setting of the resource level as
> >> requested by
> >> > > the last caller. Fixes this by introducing a struct device * to the
> >> parameter
> >> > > list for these functions.
> >> > > Signed-off-by: Romit Dasgupta <romit@ti.com>
> >> >
> >> >
> >> > This looks like the right fix to me.
> >> >
> >> > Paul, any comments?
> >>
> >>
> >> Wait a minute, I am retracting my ack.
> >>
> >>
> >> Romit, the only caller of omap_pm_dsp_set_min_opp() should be
> DSPBridge
> >> and the only caller of omap_pm_cpu_set_freq() should be CPUFreq.  So the
> >> struct device * pointer is not necessary, unless I am missing something.
> >> Can you please explain what you're trying to do?
> >>
> > I believe that omap_pm_cpu_set_freq() can be called by drivers to setup the
> > optimal vdd1 opp, right? For example MMC works at opp1 but the
> performance
> > is certainly better at opp3.When ondemand is enabled drivers need to put
> > certain constraints on vdd1 opp otherwise performance will be hurt. So, if
> > the API takes care of device level calls then drivers can call this fn.
> 
> So, the root use case is a power vs. performance policy decision.  And
> using the proposed solution, a single driver gets to make a system
> wide policy decision.  I don't like this.
> 
> For your MMC usecase, I think we need some clarifications.
> 
> What exactly does "better" performance mean.  Is it better throughput
> that is needed?  or is it really the MPU side that is not
> running/responding fast enough.
> 
> If it's throughput, then omap_pm_set_min_bus_tput() should be used.
> 
> If it's the MPU, what exactly is the problem with ondemand.  Is it
> that it doesn't respond fast enough?  Or that it never switches to a
> higher OPP.
> 
> Kevin

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Mark Brown]

On Thu, Oct 29, 2009 at 01:09:25PM +0530, Dasgupta, Romit wrote:

[Reflowed into 80 columns - you might want to look at your MUA setup.]

>      The sampling intervals for the cpufreq governors are quite large
>      and thus the latency for the frequency change to occur is large.
>      This was seen in Android UI responsiveness. The initial response
>      of the UI seems to be quite sluggish until after a while when the
>      cpufreq governors would catch up to the required MIPS.  I know
>      that Patrick (Cc'd) did some experiments with conservative
>      governor but my understanding is that it still has this basic
>      problem.

This appears to be a general problem with cpufreq on faster embedded
systems, not just OMAP.  I suspect that what we really need here is
either tuning of the existing governors or new governors better adapted
to embedded systems.  

I seem to remember from the last time I looked at this that I had a
suspicion that the relatively high transition latencies embedded systems
often have due to I2C PMICs really weren't helping here since the
governors all tend to base their polling intervals on a multiple of
those, resulting in poll times of the order of a second which are far
too long for raising the frequency.  Something like capping the latency
used when raising the frequency or scaling the poll time based on the
distance from the maximum frequency looked like a useful approach -
certainly, claiming a very low transition latency avoids the UI-visible
issue.

RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Cousson, Benoit]

Hi Romit,

>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Dasgupta, Romit
>
> Paul/Kevin,
>                       As Madhu explained it looks like there are instances
> where we forcibly need to bump up to a higher CPU + L3 frequencies (VDD1 +
> VDD2 scaling). I understand that this should be done by cpufreq governors
> but here is reason that I think the current cpufreq governors won't be
> able to handle.
>
> Large latency response:
>
>      The sampling intervals for the cpufreq governors are quite large and
> thus the latency for the frequency change to occur is large. This was seen
> in Android UI responsiveness. The initial response of the UI seems to be
> quite sluggish until after a while when the cpufreq governors would catch
> up to the required MIPS.  I know that Patrick (Cc'd) did some experiments
> with conservative governor but my understanding is that it still has this
> basic problem.

In fact, this is Mike who started that analysis. We discussed that internally and our point is that if the CPUFreq ondemand or conservative heuristic is not able to increase quickly enough the CPU need to handle correctly the UI, we have to somehow improve or modify the governor in order to provide it a extra information in term of constraint maybe in order to increase immediately the frequency.

This should not be done in the low level omap_pm code; this is not the right level to do that. The issue is in the ondemand and must be fixed there.

Regards,
Benoit


> Tied to the above is necessity for high MIPS for short duration:
>
> I also presume that there might be situations where we need very high MIPS
> but for a very very short interval of time. This would never bump up the
> frequency as it would more or less be ignored by the cpufreq governors.
>
> Please let me know what you think.
> Thanks,
> -Romit
>
>
> > -----Original Message-----
> > From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> > Sent: Thursday, October 29, 2009 4:15 AM
> > To: Chikkature Rajashekar, Madhusudhan
> > Cc: 'Paul Walmsley'; Dasgupta, Romit; 'linux-omap@vger.kernel.org'
> > Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> > framework functions
> >
> > "Madhusudhan" <madhu.cr@ti.com> writes:
> >
> > >> -----Original Message-----
> > >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > >> owner@vger.kernel.org] On Behalf Of Paul Walmsley
> > >> Sent: Wednesday, October 28, 2009 1:38 PM
> > >> To: Kevin Hilman
> > >> Cc: Dasgupta\, Romit; linux-omap\@vger.kernel.org
> > >> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> > >> framework functions
> > >>
> > >> On Tue, 13 Oct 2009, Kevin Hilman wrote:
> > >>
> > >> > "Dasgupta, Romit" <romit@ti.com> writes:
> > >> >
> > >> > > (Tested on Zoom2).
> > >> > >
> > >> > > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using
> > their
> > >> own
> > >> > > struct device *. This is a problem because invoking these
> functions
> > >> from
> > >> > > different clients would result in setting of the resource level
> as
> > >> requested by
> > >> > > the last caller. Fixes this by introducing a struct device * to
> the
> > >> parameter
> > >> > > list for these functions.
> > >> > > Signed-off-by: Romit Dasgupta <romit@ti.com>
> > >> >
> > >> >
> > >> > This looks like the right fix to me.
> > >> >
> > >> > Paul, any comments?
> > >>
> > >>
> > >> Wait a minute, I am retracting my ack.
> > >>
> > >>
> > >> Romit, the only caller of omap_pm_dsp_set_min_opp() should be
> > DSPBridge
> > >> and the only caller of omap_pm_cpu_set_freq() should be CPUFreq.  So
> the
> > >> struct device * pointer is not necessary, unless I am missing
> something.
> > >> Can you please explain what you're trying to do?
> > >>
> > > I believe that omap_pm_cpu_set_freq() can be called by drivers to
> setup the
> > > optimal vdd1 opp, right? For example MMC works at opp1 but the
> > performance
> > > is certainly better at opp3.When ondemand is enabled drivers need to
> put
> > > certain constraints on vdd1 opp otherwise performance will be hurt. So,
> if
> > > the API takes care of device level calls then drivers can call this fn.
> >
> > So, the root use case is a power vs. performance policy decision.  And
> > using the proposed solution, a single driver gets to make a system
> > wide policy decision.  I don't like this.
> >
> > For your MMC usecase, I think we need some clarifications.
> >
> > What exactly does "better" performance mean.  Is it better throughput
> > that is needed?  or is it really the MPU side that is not
> > running/responding fast enough.
> >
> > If it's throughput, then omap_pm_set_min_bus_tput() should be used.
> >
> > If it's the MPU, what exactly is the problem with ondemand.  Is it
> > that it doesn't respond fast enough?  Or that it never switches to a
> > higher OPP.
> >
> > Kevin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Dasgupta, Romit]

Hello Benoit,
                        One comment below:
> 
> In fact, this is Mike who started that analysis. We discussed that internally and
> our point is that if the CPUFreq ondemand or conservative heuristic is not able
> to increase quickly enough the CPU need to handle correctly the UI, we have
> to somehow improve or modify the governor in order to provide it a extra
> information in term of constraint maybe in order to increase immediately the
> frequency.
The information as you mention needs to be supplied by the driver. The governor would then act on behalf of the driver! 
This begs for a new governor API or a signature change to an existing governor API.
> 
> This should not be done in the low level omap_pm code; this is not the right
> level to do that. The issue is in the ondemand and must be fixed there.
> 
At the end of the day it would still be the driver making the decision! 

Regards,
-Romit

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Kevin Hilman]

"Dasgupta, Romit" <romit@ti.com> writes:

> Hello Benoit,
>                         One comment below:
>> 
>> In fact, this is Mike who started that analysis. We discussed that internally and
>> our point is that if the CPUFreq ondemand or conservative heuristic is not able
>> to increase quickly enough the CPU need to handle correctly the UI, we have
>> to somehow improve or modify the governor in order to provide it a extra
>> information in term of constraint maybe in order to increase immediately the
>> frequency.
>
> The information as you mention needs to be supplied by the
> driver. The governor would then act on behalf of the driver!  This
> begs for a new governor API or a signature change to an existing
> governor API.
>
>> This should not be done in the low level omap_pm code; this is not
>> the right level to do that. The issue is in the ondemand and must
>> be fixed there.
> 
> At the end of the day it would still be the driver making the
> decision!

No.  The drivers can give hints about their requirements, but the
drivers don't make decisions that are system wide.  The govenor acts
on behalf of the entire system based on multiple inputs, not any one
driver.

Benoit's point (and I agree with) is that this is a *system wide*
problem that needs a *system wide* solution.  I agree that tweaked or
new governor is the right approach to solving this for the long term,

In the mean time, I have a couple ideas for experimentation.

Ultimately, we're still talking about a power vs. perfomance tradeoff,
which is a system wide choice that should be left to the system
integrator (or maybe even end user.)  If performance is desired over
power (like maybe when the UI is active), there are couple things that
could be done

1) Switch to performance governor, 

2) or better, keep ondemand but use with CPUfreq policy changes

With CPUfreq policies, you can change which OPPs are available to the
system.

To see the currently available OPPs and the min/max settings:

/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies        
600000 550000 500000 250000 125000                                              
/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq                     
600000                                                                          
/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq                     
125000                                                                          

To make OPP3 the minimum OPP, all that's needed is:

/sys/devices/system/cpu/cpu0/cpufreq # echo 500000 > scaling_min_freq           

Changing the min freq is what you are trying to do from the MMC
driver.  The difference here is that since this is a system wide
policy decision, it should be done a system wide level.

Kevin

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Mike Turquette]

Kevin Hilman wrote:
> "Dasgupta, Romit" <romit@ti.com> writes:
> 
>> Hello Benoit,
>>                         One comment below:
>>> In fact, this is Mike who started that analysis. We discussed that internally and
>>> our point is that if the CPUFreq ondemand or conservative heuristic is not able
>>> to increase quickly enough the CPU need to handle correctly the UI, we have
>>> to somehow improve or modify the governor in order to provide it a extra
>>> information in term of constraint maybe in order to increase immediately the
>>> frequency.
>> The information as you mention needs to be supplied by the
>> driver. The governor would then act on behalf of the driver!  This
>> begs for a new governor API or a signature change to an existing
>> governor API.
>>
>>> This should not be done in the low level omap_pm code; this is not
>>> the right level to do that. The issue is in the ondemand and must
>>> be fixed there.
>> At the end of the day it would still be the driver making the
>> decision!
> 
> No.  The drivers can give hints about their requirements, but the
> drivers don't make decisions that are system wide.  The govenor acts
> on behalf of the entire system based on multiple inputs, not any one
> driver.
> 
> Benoit's point (and I agree with) is that this is a *system wide*
> problem that needs a *system wide* solution.  I agree that tweaked or
> new governor is the right approach to solving this for the long term,

An assumption in this thread is that ondemand/conservative can't scale 
fast enough, but that is not true.  The Android UI sluggishness 
mentioned by Benoit was solved by lowering the cpufreq 
transition_latency time from 10 million ns to 300,000ns.  I have not 
gotten the exact worst case time that it takes for voltage to scale up 
and down from the hardware guys, but through some email exchanges it was 
agreed that this value is safe.

I've pushed the patch that fixed transition_latency to the list.  Please 
see thread "decrease cpufreq transition latency".  This should hopefully 
cure a lot of performance/user experience pain and help us remove policy 
from drivers.

> In the mean time, I have a couple ideas for experimentation.
> 
> Ultimately, we're still talking about a power vs. perfomance tradeoff,
> which is a system wide choice that should be left to the system
> integrator (or maybe even end user.)  If performance is desired over
> power (like maybe when the UI is active), there are couple things that
> could be done
> 
> 1) Switch to performance governor, 
> 
> 2) or better, keep ondemand but use with CPUfreq policy changes
> 
> With CPUfreq policies, you can change which OPPs are available to the
> system.
> 
> To see the currently available OPPs and the min/max settings:
> 
> /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies        
> 600000 550000 500000 250000 125000                                              
> /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq                     
> 600000                                                                          
> /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq                     
> 125000                                                                          
> 
> To make OPP3 the minimum OPP, all that's needed is:
> 
> /sys/devices/system/cpu/cpu0/cpufreq # echo 500000 > scaling_min_freq           
> 
> Changing the min freq is what you are trying to do from the MMC
> driver.  The difference here is that since this is a system wide
> policy decision, it should be done a system wide level.
> 
> Kevin
> 

RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Madhusudhan]

> -----Original Message-----
> From: Mike Turquette [mailto:mturquette@ti.com]
> Sent: Thursday, October 29, 2009 4:38 PM
> To: Kevin Hilman
> Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan;
> 'Paul Walmsley'; linux-omap@vger.kernel.org; Titiano, Patrick
> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
> 
> Kevin Hilman wrote:
> > "Dasgupta, Romit" <romit@ti.com> writes:
> >
> >> Hello Benoit,
> >>                         One comment below:
> >>> In fact, this is Mike who started that analysis. We discussed that
> internally and
> >>> our point is that if the CPUFreq ondemand or conservative heuristic is
> not able
> >>> to increase quickly enough the CPU need to handle correctly the UI, we
> have
> >>> to somehow improve or modify the governor in order to provide it a
> extra
> >>> information in term of constraint maybe in order to increase
> immediately the
> >>> frequency.
> >> The information as you mention needs to be supplied by the
> >> driver. The governor would then act on behalf of the driver!  This
> >> begs for a new governor API or a signature change to an existing
> >> governor API.
> >>
> >>> This should not be done in the low level omap_pm code; this is not
> >>> the right level to do that. The issue is in the ondemand and must
> >>> be fixed there.
> >> At the end of the day it would still be the driver making the
> >> decision!
> >
> > No.  The drivers can give hints about their requirements, but the
> > drivers don't make decisions that are system wide.  The govenor acts
> > on behalf of the entire system based on multiple inputs, not any one
> > driver.
> >
> > Benoit's point (and I agree with) is that this is a *system wide*
> > problem that needs a *system wide* solution.  I agree that tweaked or
> > new governor is the right approach to solving this for the long term,
> 
> An assumption in this thread is that ondemand/conservative can't scale
> fast enough, but that is not true.  The Android UI sluggishness
> mentioned by Benoit was solved by lowering the cpufreq
> transition_latency time from 10 million ns to 300,000ns.  I have not
> gotten the exact worst case time that it takes for voltage to scale up
> and down from the hardware guys, but through some email exchanges it was
> agreed that this value is safe.
> 
> I've pushed the patch that fixed transition_latency to the list.  Please
> see thread "decrease cpufreq transition latency".  This should hopefully
> cure a lot of performance/user experience pain and help us remove policy
> from drivers.
> 
Hi Kevin, Mike,

Let us consider the MMC scenario. Below are the throughput numbers with
different governors.

Performance:
Write: 5.47MB/Sec
Read: 15.3MB/Sec

Ondemand:
Write: 4.2 MB/Sec
Read: 9.8 MB/Sec

Conservative:
Write: 4.9MB/Sec
Read: 12.16MB/Sec

These numbers show that "conservative" is better than ondemand but the
throughput numbers are still less than "performance". 

Instead, if the driver holds the vdd1 opp to opp3 the throughput numbers
were relatively close to "performance" governor. The logic I am talking
about is that the drivers should be intelligent enough to hold the opp at
Opp3 only when there is an active transfer. Once the transfer is done
release it back to opp1. Does this make sense? 

Otherwise, do you guys think there is room to improve conservative governor
further?

Regards,
Madhu


> > In the mean time, I have a couple ideas for experimentation.
> >
> > Ultimately, we're still talking about a power vs. perfomance tradeoff,
> > which is a system wide choice that should be left to the system
> > integrator (or maybe even end user.)  If performance is desired over
> > power (like maybe when the UI is active), there are couple things that
> > could be done
> >
> > 1) Switch to performance governor,
> >
> > 2) or better, keep ondemand but use with CPUfreq policy changes
> >
> > With CPUfreq policies, you can change which OPPs are available to the
> > system.
> >
> > To see the currently available OPPs and the min/max settings:
> >
> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies
> > 600000 550000 500000 250000 125000
> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq
> > 600000
> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq
> > 125000
> >
> > To make OPP3 the minimum OPP, all that's needed is:
> >
> > /sys/devices/system/cpu/cpu0/cpufreq # echo 500000 > scaling_min_freq
> >
> > Changing the min freq is what you are trying to do from the MMC
> > driver.  The difference here is that since this is a system wide
> > policy decision, it should be done a system wide level.
> >
> > Kevin
> >

Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Kevin Hilman]

"Madhusudhan" <madhu.cr@ti.com> writes:

>> -----Original Message-----
>> From: Mike Turquette [mailto:mturquette@ti.com]
>> Sent: Thursday, October 29, 2009 4:38 PM
>> To: Kevin Hilman
>> Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan;
>> 'Paul Walmsley'; linux-omap@vger.kernel.org; Titiano, Patrick
>> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
>> framework functions
>> 
>> Kevin Hilman wrote:
>> > "Dasgupta, Romit" <romit@ti.com> writes:
>> >
>> >> Hello Benoit,
>> >>                         One comment below:
>> >>> In fact, this is Mike who started that analysis. We discussed that
>> internally and
>> >>> our point is that if the CPUFreq ondemand or conservative heuristic is
>> not able
>> >>> to increase quickly enough the CPU need to handle correctly the UI, we
>> have
>> >>> to somehow improve or modify the governor in order to provide it a
>> extra
>> >>> information in term of constraint maybe in order to increase
>> immediately the
>> >>> frequency.
>> >> The information as you mention needs to be supplied by the
>> >> driver. The governor would then act on behalf of the driver!  This
>> >> begs for a new governor API or a signature change to an existing
>> >> governor API.
>> >>
>> >>> This should not be done in the low level omap_pm code; this is not
>> >>> the right level to do that. The issue is in the ondemand and must
>> >>> be fixed there.
>> >> At the end of the day it would still be the driver making the
>> >> decision!
>> >
>> > No.  The drivers can give hints about their requirements, but the
>> > drivers don't make decisions that are system wide.  The govenor acts
>> > on behalf of the entire system based on multiple inputs, not any one
>> > driver.
>> >
>> > Benoit's point (and I agree with) is that this is a *system wide*
>> > problem that needs a *system wide* solution.  I agree that tweaked or
>> > new governor is the right approach to solving this for the long term,
>> 
>> An assumption in this thread is that ondemand/conservative can't scale
>> fast enough, but that is not true.  The Android UI sluggishness
>> mentioned by Benoit was solved by lowering the cpufreq
>> transition_latency time from 10 million ns to 300,000ns.  I have not
>> gotten the exact worst case time that it takes for voltage to scale up
>> and down from the hardware guys, but through some email exchanges it was
>> agreed that this value is safe.
>> 
>> I've pushed the patch that fixed transition_latency to the list.  Please
>> see thread "decrease cpufreq transition latency".  This should hopefully
>> cure a lot of performance/user experience pain and help us remove policy
>> from drivers.
>> 
> Hi Kevin, Mike,
>
> Let us consider the MMC scenario. Below are the throughput numbers with
> different governors.
>
> Performance:
> Write: 5.47MB/Sec
> Read: 15.3MB/Sec
>
> Ondemand:
> Write: 4.2 MB/Sec
> Read: 9.8 MB/Sec
>
> Conservative:
> Write: 4.9MB/Sec
> Read: 12.16MB/Sec
>
> These numbers show that "conservative" is better than ondemand but the
> throughput numbers are still less than "performance". 

No surprises there.

> Instead, if the driver holds the vdd1 opp to opp3 the throughput numbers
> were relatively close to "performance" governor. The logic I am talking
> about is that the drivers should be intelligent enough to hold the opp at
> Opp3 only when there is an active transfer. Once the transfer is done
> release it back to opp1. Does this make sense? 

I think you're missing my point.

What you're trying to do is to allow a driver to make a power
vs. performance policy decision.  You're assuming that the user (or
system integrator) will always choose performance over power.  What if
the user is willing to accept a slightly slower system if it extends
battery life?

The point I'm trying to make is that these kinds of policy decisions
simply do not belong in drivers.

Kevin

> Otherwise, do you guys think there is room to improve conservative governor
> further?
>
> Regards,
> Madhu
>
>
>> > In the mean time, I have a couple ideas for experimentation.
>> >
>> > Ultimately, we're still talking about a power vs. perfomance tradeoff,
>> > which is a system wide choice that should be left to the system
>> > integrator (or maybe even end user.)  If performance is desired over
>> > power (like maybe when the UI is active), there are couple things that
>> > could be done
>> >
>> > 1) Switch to performance governor,
>> >
>> > 2) or better, keep ondemand but use with CPUfreq policy changes
>> >
>> > With CPUfreq policies, you can change which OPPs are available to the
>> > system.
>> >
>> > To see the currently available OPPs and the min/max settings:
>> >
>> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies
>> > 600000 550000 500000 250000 125000
>> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq
>> > 600000
>> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq
>> > 125000
>> >
>> > To make OPP3 the minimum OPP, all that's needed is:
>> >
>> > /sys/devices/system/cpu/cpu0/cpufreq # echo 500000 > scaling_min_freq
>> >
>> > Changing the min freq is what you are trying to do from the MMC
>> > driver.  The difference here is that since this is a system wide
>> > policy decision, it should be done a system wide level.
>> >
>> > Kevin
>> >

RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Dasgupta, Romit]

> An assumption in this thread is that ondemand/conservative can't scale
> fast enough, but that is not true.  The Android UI sluggishness
> mentioned by Benoit was solved by lowering the cpufreq
> transition_latency time from 10 million ns to 300,000ns.  I have not
> gotten the exact worst case time that it takes for voltage to scale up
> and down from the hardware guys, but through some email exchanges it was
> agreed that this value is safe.
> 
This has the effect of arming the timers more frequently and hence more power consumption! But I guess as Kevin says, if the user wants to sacrifice power for performance this might be ok. 

RE: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Titiano, Patrick]

>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Friday, October 30, 2009 12:33 AM
> To: Chikkature Rajashekar, Madhusudhan
> Cc: Turquette, Mike; Dasgupta, Romit; Cousson, Benoit; 'Paul Walmsley';
> linux-omap@vger.kernel.org; Titiano, Patrick
> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
>
> "Madhusudhan" <madhu.cr@ti.com> writes:
>
> >> -----Original Message-----
> >> From: Mike Turquette [mailto:mturquette@ti.com]
> >> Sent: Thursday, October 29, 2009 4:38 PM
> >> To: Kevin Hilman
> >> Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar,
> Madhusudhan;
> >> 'Paul Walmsley'; linux-omap@vger.kernel.org; Titiano, Patrick
> >> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> >> framework functions
> >>
> >> Kevin Hilman wrote:
> >> > "Dasgupta, Romit" <romit@ti.com> writes:
> >> >
> >> >> Hello Benoit,
> >> >>                         One comment below:
> >> >>> In fact, this is Mike who started that analysis. We discussed that
> >> internally and
> >> >>> our point is that if the CPUFreq ondemand or conservative heuristic
> is
> >> not able
> >> >>> to increase quickly enough the CPU need to handle correctly the UI,
> we
> >> have
> >> >>> to somehow improve or modify the governor in order to provide it a
> >> extra
> >> >>> information in term of constraint maybe in order to increase
> >> immediately the
> >> >>> frequency.
> >> >> The information as you mention needs to be supplied by the
> >> >> driver. The governor would then act on behalf of the driver!  This
> >> >> begs for a new governor API or a signature change to an existing
> >> >> governor API.
> >> >>
> >> >>> This should not be done in the low level omap_pm code; this is not
> >> >>> the right level to do that. The issue is in the ondemand and must
> >> >>> be fixed there.
> >> >> At the end of the day it would still be the driver making the
> >> >> decision!
> >> >
> >> > No.  The drivers can give hints about their requirements, but the
> >> > drivers don't make decisions that are system wide.  The govenor acts
> >> > on behalf of the entire system based on multiple inputs, not any one
> >> > driver.
> >> >
> >> > Benoit's point (and I agree with) is that this is a *system wide*
> >> > problem that needs a *system wide* solution.  I agree that tweaked or
> >> > new governor is the right approach to solving this for the long term,
> >>
> >> An assumption in this thread is that ondemand/conservative can't scale
> >> fast enough, but that is not true.  The Android UI sluggishness
> >> mentioned by Benoit was solved by lowering the cpufreq
> >> transition_latency time from 10 million ns to 300,000ns.  I have not
> >> gotten the exact worst case time that it takes for voltage to scale up
> >> and down from the hardware guys, but through some email exchanges it
> was
> >> agreed that this value is safe.
> >>
> >> I've pushed the patch that fixed transition_latency to the list.
> Please
> >> see thread "decrease cpufreq transition latency".  This should
> hopefully
> >> cure a lot of performance/user experience pain and help us remove
> policy
> >> from drivers.
> >>
> > Hi Kevin, Mike,
> >
> > Let us consider the MMC scenario. Below are the throughput numbers with
> > different governors.
> >
> > Performance:
> > Write: 5.47MB/Sec
> > Read: 15.3MB/Sec
> >
> > Ondemand:
> > Write: 4.2 MB/Sec
> > Read: 9.8 MB/Sec
> >
> > Conservative:
> > Write: 4.9MB/Sec
> > Read: 12.16MB/Sec
> >
> > These numbers show that "conservative" is better than ondemand but the
> > throughput numbers are still less than "performance".
>
> No surprises there.
>
> > Instead, if the driver holds the vdd1 opp to opp3 the throughput numbers
> > were relatively close to "performance" governor. The logic I am talking
> > about is that the drivers should be intelligent enough to hold the opp
> at
> > Opp3 only when there is an active transfer. Once the transfer is done
> > release it back to opp1. Does this make sense?
>
> I think you're missing my point.
>
> What you're trying to do is to allow a driver to make a power
> vs. performance policy decision.  You're assuming that the user (or
> system integrator) will always choose performance over power.  What if
> the user is willing to accept a slightly slower system if it extends
> battery life?
>
> The point I'm trying to make is that these kinds of policy decisions
> simply do not belong in drivers.
>
> Kevin

Kevin, this is absolutely correct. I think this is our number one issue in terms of PM policy.
Today we enterely rely on a single "default" governor (ondemand) and expect it to always take the best decision in any circumstances, solely based on the monitored CPU load. This is quite unrealistic.
I see 4 missing points in our PM SW Framework today:

1/ Hints from low-level drivers to PM policy so that it knows runtime platform activities and how to react accordingly.
E.g:
 - I am DMA-driven, my CPU load is low but I need low latencies (e.g. USB/MMC transfers, etc ...)
 - I am generating huge data transfers, I need high bus speed (e.g. CAMERA)
 - I do not support DVFS
 - I do not support OFF-mode
 - ...

2/ System-wide PM policy, taking other parameters than CPU load to take decisions (i.e hints from low-level drivers, etc).
Note that it may be multiple policies, not only one.
Also note that OPP is not the only one parameter to control. There is also the CPU C-State, directly impacting system latencies, to be dynamically controlled by some PM policy.

3/ Hints from user side to decide whether or not to prefer performances over power.

4/ Fine-tuned PM Poliy. We use ondemand default configuration, develop on a different platform and probably configured to react "good-enough" on any platform. Can't expect it to perform perfectly on our platform (that's what Mike showed).

Patrick.



>
> > Otherwise, do you guys think there is room to improve conservative
> governor
> > further?
> >
> > Regards,
> > Madhu
> >
> >
> >> > In the mean time, I have a couple ideas for experimentation.
> >> >
> >> > Ultimately, we're still talking about a power vs. perfomance tradeoff,
> >> > which is a system wide choice that should be left to the system
> >> > integrator (or maybe even end user.)  If performance is desired over
> >> > power (like maybe when the UI is active), there are couple things
> that
> >> > could be done
> >> >
> >> > 1) Switch to performance governor,
> >> >
> >> > 2) or better, keep ondemand but use with CPUfreq policy changes
> >> >
> >> > With CPUfreq policies, you can change which OPPs are available to the
> >> > system.
> >> >
> >> > To see the currently available OPPs and the min/max settings:
> >> >
> >> > /sys/devices/system/cpu/cpu0/cpufreq # cat
> scaling_available_frequencies
> >> > 600000 550000 500000 250000 125000
> >> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq
> >> > 600000
> >> > /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_min_freq
> >> > 125000
> >> >
> >> > To make OPP3 the minimum OPP, all that's needed is:
> >> >
> >> > /sys/devices/system/cpu/cpu0/cpufreq # echo 500000 > scaling_min_freq
> >> >
> >> > Changing the min freq is what you are trying to do from the MMC
> >> > driver.  The difference here is that since this is a system wide
> >> > policy decision, it should be done a system wide level.
> >> >
> >> > Kevin
> >> >