[Bug 8081] Conservative governor sets wrong and too high sampling rates

[Bug 8081] Conservative governor sets wrong and too high sampling rates

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8081





------- Additional Comments From ferriste@libero.it  2007-02-25 08:37 -------
Created an attachment (id=10530)
 --> (http://bugzilla.kernel.org/attachment.cgi?id=10530&action=view)
This is a simple patch to fix the bug. Apply it at conservative.c


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[Rafał Bilski]

> ------- Additional Comments From ferriste@libero.it  2007-02-25 08:37 -------
> Created an attachment (id=10530)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=10530&action=view)
> This is a simple patch to fix the bug. Apply it at conservative.c
NACK from me. Current values are working for me. If these values are 
not good for You then write patch to Kconfig which will allow user to 
change sampling rate during "make config". Later "make oldconfig" will 
preserve Your values.

Rafa³


----------------------------------------------------------------------
Przedluz domene.PL za 75 z³ >> http://link.interia.pl/f1a19

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[stefano ferri]

Hi Rafal, I think you have not understood what is the core of the problem...
The problem is not to make possible to change sampling rates, anyone with the current code of the kernel can do it.
The problem is that conservative has a 10x factor of polling times if compared to ondemand.

>The CPUfreq governor "conservative", much like the "ondemand"
>governor, sets the CPU depending on the current usage. It differs in
>behavior in that it gracefully increases and decreases the CPU speed
>rather than jumping to max speed the moment there is any load on the
>CPU.

Right, but if ondemand has a minimum polling time of 99500 milliseconds, also conservative should have it, even if it "gracefully" increases and decreases the CPU speed. The policy of the transition of a governor is another thing. It is a kernel space governor and it should do the things gracefully but rapidly ;-)!

The problem is that line 497 in the conservative.c code.
I don't know if the problem depends on my specific hardware, but my system does not respond at all to a variable system load witout deleting that 10x factor, my cpu goes at 400 Mhz all the time, also transition to 800 Mhz are rare.

>NACK from me. Current values are working for me. If these values are
>not good for You then write patch to Kconfig which will allow user to
>change sampling rate during "make config". Later "make oldconfig" will
>preserve Your values.

I said, it's not that the problem. Users will NOT be able to set a decent polling time if that 10x factor wil not be removed. I can choose a minium time of 995000 millisecond (1 second!). Now that I recompiled I obtain a 99500 with both ondemand and conservative, as it should be.
And I see the frequency increasing and decreasing gracefully :-)!

Stefano




---------- Initial Header -----------

From      : "Rafal Bilski" rafalbilski@interia.pl
To          : ferriste@libero.it
Cc          : cpufreq@lists.linux.org.uk
Date      : Sun, 25 Feb 2007 21:29:59 +0100
Subject : Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates







> > ------- Additional Comments From ferriste@libero.it  2007-02-25 08:37 -------
> > Created an attachment (id=10530)
> >  --> (http://bugzilla.kernel.org/attachment.cgi?id=10530&action=view)
> > This is a simple patch to fix the bug. Apply it at conservative.c
> NACK from me. Current values are working for me. If these values are
> not good for You then write patch to Kconfig which will allow user to
> change sampling rate during "make config". Later "make oldconfig" will 
> preserve Your values.
>
> Rafal
>
>
> ----------------------------------------------------------------------
> Przedluz domene.PL za 75 zl >> http://link.interia.pl/f1a19
>
> 


------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada25feb07

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[stefano ferri]

Hi Rafal, I think you have not understood what is the core of the problem...
The problem is not to make possible to change sampling rates, anyone with the current code of the kernel can do it.
The problem is that conservative has a 10x factor of polling times if compared to ondemand.

>The CPUfreq governor "conservative", much like the "ondemand"
>governor, sets the CPU depending on the current usage. It differs in
>behavior in that it gracefully increases and decreases the CPU speed
>rather than jumping to max speed the moment there is any load on the
>CPU.

Right, but if ondemand has a minimum polling time of 99500 milliseconds, also conservative should have it, even if it "gracefully" increases and decreases the CPU speed. The policy of the transition of a governor is another thing. It is a kernel space governor and it should do the things gracefully but rapidly ;-)!

The problem is that line 497 in the conservative.c code.
I don't know if the problem depends on my specific hardware, but my system does not respond at all to a variable system load witout deleting that 10x factor, my cpu goes at 400 Mhz all the time, also transition to 800 Mhz are rare.

>NACK from me. Current values are working for me. If these values are
>not good for You then write patch to Kconfig which will allow user to
>change sampling rate during "make config". Later "make oldconfig" will
>preserve Your values.

I said, it's not that the problem. Users will NOT be able to set a decent polling time if that 10x factor wil not be removed. I can choose a minium time of 995000 millisecond (1 second!). Now that I recompiled I obtain a 99500 with both ondemand and conservative, as it should be.
And I see the frequency increasing and decreasing gracefully :-)!

Stefano




---------- Initial Header -----------

From      : "Rafal Bilski" rafalbilski@interia.pl
To          : ferriste@libero.it
Cc          : cpufreq@lists.linux.org.uk
Date      : Sun, 25 Feb 2007 21:29:59 +0100
Subject : Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates







> > ------- Additional Comments From ferriste@libero.it  2007-02-25 08:37 -------
> > Created an attachment (id=10530)
> >  --> (http://bugzilla.kernel.org/attachment.cgi?id=10530&action=view)
> > This is a simple patch to fix the bug. Apply it at conservative.c
> NACK from me. Current values are working for me. If these values are
> not good for You then write patch to Kconfig which will allow user to
> change sampling rate during "make config". Later "make oldconfig" will 
> preserve Your values.
>
> Rafal
>
>
> ----------------------------------------------------------------------
> Przedluz domene.PL za 75 zl >> http://link.interia.pl/f1a19
>
> 


------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada25feb07

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[Rafał Bilski]

> Hi Rafal
Hi Stefano
> I think you have not understood what is the core of the problem...
Maybe. It is weekend and it is late and conservative works for me.
> The problem is not to make possible to change sampling rates, anyone with the current code of the kernel can do it.
> The problem is that conservative has a 10x factor of polling times if compared to ondemand.
> 
>> The CPUfreq governor "conservative", much like the "ondemand"
>> governor, sets the CPU depending on the current usage. It differs in
>> behavior in that it gracefully increases and decreases the CPU speed
>> rather than jumping to max speed the moment there is any load on the
>> CPU.
> 
> Right, but if ondemand has a minimum polling time of 99500 milliseconds, 
> also conservative should have it, even if it "gracefully" increases and 
> decreases the CPU speed. The policy of the transition of a governor 
> is another thing. It is a kernel space governor and it should do the things 
> gracefully but rapidly ;-)!
I don't like word "rapidly" here. Ondemand is doing things rapidly and as 
result my CPU is near the max frequency most time. Fan is making noise :-(
> The problem is that line 497 in the conservative.c code.
> I don't know if the problem depends on my specific hardware, 
> but my system does not respond at all to a variable system load 
> without deleting that 10x factor, my cpu goes at 400 Mhz all the time, 
> also transition to 800 Mhz are rare.
My CPU goes at 533MHz most the time. Transitions to higher frequencies 
are rare and happen only if there is constant load.
Check http://elke.homelinux.net/index.cgi
Not sure why my CPU was 300% idle once, but rest seems to be OK.
Red line is fan on temperature. Green line is fan off temperature.
Polling at 10s interval.
Please clarify me this problem. If You have 100% constant load (eg. You 
are compiling Thunderbird) CPU speed is increasing or not? Or Your case is, 
for example, RTorrent with shedule which is using 100% CPU for 1s at 10s 
interval? Would You like to change CPU frequency for this 1s to higher 
value?
> 
>> NACK from me. Current values are working for me. If these values are
>> not good for You then write patch to Kconfig which will allow user to
>> change sampling rate during "make config". Later "make oldconfig" will
>> preserve Your values.
> 
> I said, it's not that the problem. Users will NOT be able to set a decent polling time if that 10x factor wil not be removed. I can choose a minium time of 995000 millisecond (1 second!). Now that I recompiled I obtain a 99500 with both ondemand and conservative, as it should be.
> And I see the frequency increasing and decreasing gracefully :-)!
I have sampling rate at 2s (by default). I can lower it to 1s. I can rise 
it too. You are changing default value and min and max values. This will 
rise power consumption. Yes, I know that I can change sampling rate. But 
You are changing *default* value. If You don't like min value then change 
min value. I disagree with Your change because You are changing *powersaver* 
governor into step-by-step ondemand.
> Stefano

Rafa³


----------------------------------------------------------------------
Wolne adresy pocztowe @interia.eu >>> http://link.interia.pl/f19e8

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[stefano ferri]

> > Hi Rafal
> Hi Stefano
> > I think you have not understood what is the core of the problem...
> Maybe. It is weekend and it is late and conservative works >for me.

I was speaking seriously :-| ... Also for me it is working but without the patch  not as I wanted ... But now that I've read the archives of this mailing list (sorry I didn't read before...)  I understand a little your point of view, even if I disagree on it. I'll tell you why.

Last year the code of conservative was different ad less similar to ondemand than now. With that code (I mean a 2.6.14.6) I had these values:

sampling_rate_min 9950000
sampling_rate_max 1360065408

min= 9.95 seconds, max 1360. Ok, here there were some problems.
I contacted Alexander Clouther for this problem, and after he sent me four patches, in pratice the same code that I see on the archive of March 22, 2006 of this mailing list. Sorry if I never read the archive, I read message here only fom yesterday... So, I read in the message "[patch 2/4 MKII] " this:

>By default its ten times less responsive.

Ok, so the 10x factor compared to ondemand is a choice of developers.
Now I understand that what I thought a bug is not a real bug but a different idea about the governor.
I think that a kernel space governor that doesn't make possible a user to set a sampling rate of less than a second is not useful, it is better powernowd+userspace...
A user should be free to choose, if a developer think that the ideal samplig rate is about 1 second, ok, set this a default value but let user free to set it to 0.1 seconds in example. I cannot do a echo on sampling_rate lower than the value contained in sampling_rate_min.
Correcting that line of code I mentioned above one can choose a value between 0.0995 seconds and 9.95. I don't know what should I do with a maximum of 99.5...

I hope we can agree a little on this... If you want the kernel   set a default value of 1 second ok, but let users free to set it to a vrey lower value decreasing the value contained in sampling_rate_min.
Another important question is this: I read that Athlon 64 cpus have a too high latency time to swith form the minimum to the maximum frequency, so the ondemand governor is not a good choice because latency. Why an athlon 64 user could not have a governor increasing rapidly step by step as conservative could do with convenient values of sampling rates? I have not a direct experience with such processor.


> I don't like word "rapidly" here. Ondemand is doing things rapidly and as
> result my CPU is near the max frequency most time. Fan is making noise :-(

fan starts very rarely also with my version of conservative, ondemand, yes, makes it start for too much time.
Why don't you try?


> Please clarify me this problem. If You have 100% constant load (eg. You
> are compiling Thunderbird) CPU speed is increasing or not? Or Your case is,
> for example, RTorrent with shedule which is using 100% CPU for 1s at 10s
> interval? Would You like to change CPU frequency for this 1s to higher 
> value?

If the load is constant (as you said, when compiling) conservative increases frequency, but it takes ten second to pass from 400 Mhz to 2133, it's too much... The governor works but I think it's not very useful for a desktop use if I am not free to set a sampling rate lower than a second...

> You are changing *default* value. If You don't like min value then change
> min value. I disagree with Your change because You are changing *powersaver*
> governor into step-by-step ondemand.

If you think, the default value can remain the same, 1 or 2 seconds as now, but I would have the opportunity to set it to 0.1 seconds for example, while my sampling_rate_min is 995000, it is not possible in this condition! A conservative governor with the possibility to choose a lower sampling rate could be useful. As you said, it would be a step-by-step ondemand.

Stefano



------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada27eb07

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[Rafał Bilski]

> [...]
> Correcting that line of code I mentioned above one can choose a value between 0.0995 seconds and 9.95. I don't know what should I do with a maximum of 99.5...
Me too, but maybe there is someone using it. I don't see the reason to touch it.
> I hope we can agree a little on this... If you want the kernel 
> set a default value of 1 second ok, but let users free to set it 
> to a vrey lower value decreasing the value contained in sampling_rate_min.
I agree.
> [...]
> fan starts very rarely also with my version of conservative, ondemand, yes, makes it start for too much time.
> Why don't you try?
Current value is good for me.
>> [...]
> If the load is constant (as you said, when compiling) conservative increases 
> frequency, but it takes ten second to pass from 400 Mhz to 2133, 
> it's too much... The governor works but I think it's not very useful 
> for a desktop use if I am not free to set a sampling rate lower than a second...
It takes ten seconds for me too (66MHz step). It isn't probem for me. 
>> You are changing *default* value. If You don't like min value then change 
>> min value. I disagree with Your change because You are changing *powersaver* 
>> governor into step-by-step ondemand.
> 
> If you think, the default value can remain the same, 1 or 2 seconds as now, 
> but I would have the opportunity to set it to 0.1 seconds for example, while 
> my sampling_rate_min is 995000, it is not possible in this condition! 
> A conservative governor with the possibility to choose a lower sampling 
> rate could be useful. As you said, it would be a step-by-step ondemand.
OK. Patch below is touching only min value. It is for 2.6.20. Is it sufficent?
---
 drivers/cpufreq/cpufreq_conservative.c |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -49,12 +49,11 @@
  * All times here are in uS.
  */
 static unsigned int 				def_sampling_rate;
+static unsigned int 				min_sampling_rate;
 #define MIN_SAMPLING_RATE_RATIO			(2)
 /* for correct statistics, we need at least 10 ticks between each measure */
 #define MIN_STAT_SAMPLING_RATE			\
 			(MIN_SAMPLING_RATE_RATIO * jiffies_to_usecs(10))
-#define MIN_SAMPLING_RATE			\
-			(def_sampling_rate / MIN_SAMPLING_RATE_RATIO)
 #define MAX_SAMPLING_RATE			(500 * def_sampling_rate)
 #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(1000)
 #define DEF_SAMPLING_DOWN_FACTOR		(1)
@@ -125,7 +124,7 @@ static ssize_t show_sampling_rate_max(struct cpufreq_policy *policy, char *buf)
 
 static ssize_t show_sampling_rate_min(struct cpufreq_policy *policy, char *buf)
 {
-	return sprintf (buf, "%u\n", MIN_SAMPLING_RATE);
+	return sprintf (buf, "%u\n", min_sampling_rate);
 }
 
 #define define_one_ro(_name) 					\
@@ -173,7 +172,7 @@ static ssize_t store_sampling_rate(struct cpufreq_policy *unused,
 	ret = sscanf (buf, "%u", &input);
 
 	mutex_lock(&dbs_mutex);
-	if (ret != 1 || input > MAX_SAMPLING_RATE || input < MIN_SAMPLING_RATE) {
+	if (ret != 1 || input > MAX_SAMPLING_RATE || input < min_sampling_rate) {
 		mutex_unlock(&dbs_mutex);
 		return -EINVAL;
 	}
@@ -510,10 +509,14 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 
 			def_sampling_rate = 10 * latency *
 					DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
-
 			if (def_sampling_rate < MIN_STAT_SAMPLING_RATE)
 				def_sampling_rate = MIN_STAT_SAMPLING_RATE;
 
+			min_sampling_rate = latency *
+					DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
+			if (min_sampling_rate < MIN_STAT_SAMPLING_RATE)
+				min_sampling_rate = MIN_STAT_SAMPLING_RATE;
+
 			dbs_tuners_ins.sampling_rate = def_sampling_rate;
 
 			dbs_timer_init();

----------------------------------------------------------------------
Oficjalne konto pocztowe europejskich internautow! 
>>> http://link.interia.pl/f19e8

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[stefano ferri]

> > I hope we can agree a little on this... If you want the kernel
> > set a default value of 1 second ok, but let users free to set it
> > to a vrey lower value decreasing the value contained in sampling_rate_min.
> I agree.

Ok :-)

> Current value is good for me.

Rafal, I believe that, but you should consider that for some people current values are not the best... With the new code you wrote the governor should satisfy more users. I'll try the patch as soon as possible.
So now, if I have a default sampling rate of 199000, the min will be 19900... good


> OK. Patch below is touching only min value. It is for 2.6.20. Is it sufficent?

Yes, if it will be a change in the next release of the kernel!

Thanks
Stefano








------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada28eb07

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[Rafał Bilski]

> [...]
> With the new code you wrote the governor should satisfy more users. 
> [...]
> So now, if I have a default sampling rate of 199000, the min will be 19900... good
> Oops.. wrong calculus. With the original code of the kernel default is 1990000, 
> min with your patch will be 1/10, so 199000. Could you please align the 
> min values with that of ondemand? (for my processor is 99500). 
> It should be 1/20 of the default, and the min sampling rate 
> that one can set would be about 1/10 of second.
OK. Adjusted. 
>> OK. Patch below is touching only min value. It is for 2.6.20. Is it sufficent?
> 
> Yes, if it will be a change in the next release of the kernel!
If author of this governor will accept it then probably will.

Question to Alexander Clouter:
Is this patch/change acceptable?

---
 drivers/cpufreq/cpufreq_conservative.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -49,12 +49,11 @@
  * All times here are in uS.
  */
 static unsigned int 				def_sampling_rate;
+static unsigned int 				min_sampling_rate;
 #define MIN_SAMPLING_RATE_RATIO			(2)
 /* for correct statistics, we need at least 10 ticks between each measure */
 #define MIN_STAT_SAMPLING_RATE			\
 			(MIN_SAMPLING_RATE_RATIO * jiffies_to_usecs(10))
-#define MIN_SAMPLING_RATE			\
-			(def_sampling_rate / MIN_SAMPLING_RATE_RATIO)
 #define MAX_SAMPLING_RATE			(500 * def_sampling_rate)
 #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(1000)
 #define DEF_SAMPLING_DOWN_FACTOR		(1)
@@ -125,7 +124,7 @@ static ssize_t show_sampling_rate_max(struct cpufreq_policy *policy, char *buf)
 
 static ssize_t show_sampling_rate_min(struct cpufreq_policy *policy, char *buf)
 {
-	return sprintf (buf, "%u\n", MIN_SAMPLING_RATE);
+	return sprintf (buf, "%u\n", min_sampling_rate);
 }
 
 #define define_one_ro(_name) 					\
@@ -173,7 +172,7 @@ static ssize_t store_sampling_rate(struct cpufreq_policy *unused,
 	ret = sscanf (buf, "%u", &input);
 
 	mutex_lock(&dbs_mutex);
-	if (ret != 1 || input > MAX_SAMPLING_RATE || input < MIN_SAMPLING_RATE) {
+	if (ret != 1 || input > MAX_SAMPLING_RATE || input < min_sampling_rate) {
 		mutex_unlock(&dbs_mutex);
 		return -EINVAL;
 	}
@@ -510,10 +509,13 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 
 			def_sampling_rate = 10 * latency *
 					DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
-
 			if (def_sampling_rate < MIN_STAT_SAMPLING_RATE)
 				def_sampling_rate = MIN_STAT_SAMPLING_RATE;
 
+			min_sampling_rate = def_sampling_rate / 20;
+			if (min_sampling_rate < MIN_STAT_SAMPLING_RATE)
+				min_sampling_rate = MIN_STAT_SAMPLING_RATE;
+
 			dbs_tuners_ins.sampling_rate = def_sampling_rate;
 
 			dbs_timer_init();


----------------------------------------------------------------------
Oficjalne konto pocztowe europejskich internautow! 
>>> http://link.interia.pl/f19e8

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[Alexander Clouter]

[-- Attachment #1.1.1: Type: text/plain, Size: 4864 bytes --]

Hi,

I'm pretty sure this is a Bad Idea(tm).  I originally fiddled with the 
scaling in this manner and some ratios and fixing things for one 
group of people ended up breaking things for another.

I actually recall all these problems when I first released the patch, I was 
trying to persuade the governor to react more slowly and foolishly made 
'DEF_SAMPLING_RATE_LATENCY_MULTIPLIER' 100000, bumped up from the original 
value of 1000.  It was actually Stefano Ferri who reported the bug 
originally.

I have attached the chat we had if you forgot.  This problem really lurked 
around between the merge data and 2.6.16ish[1], I CC'ed Stefano in on the 
patches and he said things worked fine after they were applied.

There are some other underlying issues and this is not the way to solve it.  

I'll look into it this weekend and let you boys'n'girls know.

Cheers

Alex

[1] a lot of cpufreq overhaul work for hotpluggable (Wed, 22 Mar 2006:
	cpufreq_conservative: align codebase with ondemand for consistancy) 
	kicked was done and the fixes I did went into that lot.  Everyone 
	seemed to concur at the time I had sorted things out then

Rafa? Bilski <rafalbilski@interia.pl> [20070228 20:39:57 +0100]:
>
> > [...]
> > With the new code you wrote the governor should satisfy more users. 
> > [...]
> > So now, if I have a default sampling rate of 199000, the min will be 19900... good
> > Oops.. wrong calculus. With the original code of the kernel default is 1990000, 
> > min with your patch will be 1/10, so 199000. Could you please align the 
> > min values with that of ondemand? (for my processor is 99500). 
> > It should be 1/20 of the default, and the min sampling rate 
> > that one can set would be about 1/10 of second.
> OK. Adjusted. 
> >> OK. Patch below is touching only min value. It is for 2.6.20. Is it sufficent?
> > 
> > Yes, if it will be a change in the next release of the kernel!
> If author of this governor will accept it then probably will.
> 
> Question to Alexander Clouter:
> Is this patch/change acceptable?
> 
> ---
>  drivers/cpufreq/cpufreq_conservative.c |   12 +++++++-----
>  1 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -49,12 +49,11 @@
>   * All times here are in uS.
>   */
>  static unsigned int 				def_sampling_rate;
> +static unsigned int 				min_sampling_rate;
>  #define MIN_SAMPLING_RATE_RATIO			(2)
>  /* for correct statistics, we need at least 10 ticks between each measure */
>  #define MIN_STAT_SAMPLING_RATE			\
>  			(MIN_SAMPLING_RATE_RATIO * jiffies_to_usecs(10))
> -#define MIN_SAMPLING_RATE			\
> -			(def_sampling_rate / MIN_SAMPLING_RATE_RATIO)
>  #define MAX_SAMPLING_RATE			(500 * def_sampling_rate)
>  #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(1000)
>  #define DEF_SAMPLING_DOWN_FACTOR		(1)
> @@ -125,7 +124,7 @@ static ssize_t show_sampling_rate_max(struct cpufreq_policy *policy, char *buf)
>  
>  static ssize_t show_sampling_rate_min(struct cpufreq_policy *policy, char *buf)
>  {
> -	return sprintf (buf, "%u\n", MIN_SAMPLING_RATE);
> +	return sprintf (buf, "%u\n", min_sampling_rate);
>  }
>  
>  #define define_one_ro(_name) 					\
> @@ -173,7 +172,7 @@ static ssize_t store_sampling_rate(struct cpufreq_policy *unused,
>  	ret = sscanf (buf, "%u", &input);
>  
>  	mutex_lock(&dbs_mutex);
> -	if (ret != 1 || input > MAX_SAMPLING_RATE || input < MIN_SAMPLING_RATE) {
> +	if (ret != 1 || input > MAX_SAMPLING_RATE || input < min_sampling_rate) {
>  		mutex_unlock(&dbs_mutex);
>  		return -EINVAL;
>  	}
> @@ -510,10 +509,13 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>  
>  			def_sampling_rate = 10 * latency *
>  					DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
> -
>  			if (def_sampling_rate < MIN_STAT_SAMPLING_RATE)
>  				def_sampling_rate = MIN_STAT_SAMPLING_RATE;
>  
> +			min_sampling_rate = def_sampling_rate / 20;
> +			if (min_sampling_rate < MIN_STAT_SAMPLING_RATE)
> +				min_sampling_rate = MIN_STAT_SAMPLING_RATE;
> +
>  			dbs_tuners_ins.sampling_rate = def_sampling_rate;
>  
>  			dbs_timer_init();
> 
> 
> ----------------------------------------------------------------------
> Oficjalne konto pocztowe europejskich internautow! 
> >>> http://link.interia.pl/f19e8
> 
> 

-- 
 _________________________________________
/ A man with one watch knows what time it \
| is. A man with two watches is never     |
\ quite sure.                             /
 -----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

[-- Attachment #1.1.2: bug-history --]
[-- Type: text/plain, Size: 11024 bytes --]

Return-Path: <ferriste@libero.it>
Received: from mx2.internal (mx2.internal [10.202.2.201])
	 by server1.messagingengine.com (Cyrus v2.3-alpha) with LMTPA;
	 Wed, 25 Jan 2006 20:03:12 -0500
X-Sieve: CMU Sieve 2.3
X-Resolved-to: jimdigriz@imapmail.org
X-Delivered-to: jimdigriz@imapmail.org
X-Mail-from: ferriste@libero.it
Received: from mail.just-the-name.co.uk (just-the-name.co.uk [213.162.97.161])
	by mx2.messagingengine.com (Postfix) with ESMTP id CF1BA159EA6B
	for <jimdigriz@imapmail.org>; Wed, 25 Jan 2006 20:03:13 -0500 (EST)
Received: from smtp20.libero.it (smtp20.libero.it [193.70.192.147])
	by mail.just-the-name.co.uk (Postfix) with ESMTP id 0A484404D31
	for <alex-kernel@digriz.org.uk>; Thu, 26 Jan 2006 01:02:58 +0000 (GMT)
Received: from localhost (172.16.1.84) by smtp20.libero.it (7.0.027-DD01)
        id 439D916F035D43E7 for alex-kernel@digriz.org.uk; Thu, 26 Jan 2006 02:02:38 +0100
Received: from smtp20.libero.it ([172.16.1.76])
 by localhost (asav5.libero.it [193.70.192.154]) (amavisd-new, port 10024)
 with ESMTP id 24093-07-2 for <alex-kernel@digriz.org.uk>;
 Thu, 26 Jan 2006 02:02:38 +0100 (CET)
Received: from libero.it (172.16.1.88) by smtp20.libero.it (7.0.027-DD01)
        id 431C3BFF016FC3F5 for alex-kernel@digriz.org.uk; Thu, 26 Jan 2006 02:02:38 +0100
Date: Thu, 26 Jan 2006 02:02:37 +0100
Message-Id: <ITODKD$AB9003C0C7E167A2B13A55F4CC420ABF@libero.it>
Subject: Bug in conservative governor?
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
From: "stefano ferri" <ferriste@libero.it>
To: "alex-kernel" <alex-kernel@digriz.org.uk>
X-XaM3-API-Version: 4.3 (R1) (B3pl11)
X-SenderIP: 87.3.140.46
X-Scanned: with antispam and antivirus automated system at libero.it
Content-Length: 1382
Lines: 38

Hello. I would expose you a problem with the conservatice governor that I=
 think is caused by a wrong constant set in the file cpufreq_conservative=
.c, in the kernel source.
I am running a 2.6.14.6 on slackware 10.2, on a laptop with an Amd Athlon=
 xp-m 2800+, so the scaling driver is powernow-k7.
The problem is this: when I set the conservative governor, in the folder =
/sys/devices/system/cpu/cpu0/cpufreq/conservative this is what I read:

sampling_rate_min   9950000
sampling_rate_max   1360065408

this make the governor useless, because the minimum polling period is 9.9=
5 seconds. Instead, with the ondemand governor the values are these:

sampling_rate_min   99500
sampling_rate_max   99500000

with such values the ondemand governor can work fine.
You can observe that the sampling_rate min of conservative is exactly 100=
 times greater than ondemand. Looking at the kernel source I've found thi=
s:

file cpufreq_conservative.c , line 58
#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(100000)

file cpufreq_ondemand.c , line 53
#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(1000)

the constant defined in the first file is exactly 100 times greater than =
that defined in cpufreq_ondemand.c . This is normal or could be this the =
problem? Or is it caused by my hardware? I think I've loaded all necessar=
y modules to make these governors work.
Thanks

Stefano




Return-Path: <ferriste@libero.it>
Received: from mx4.internal (mx4.internal [10.202.2.203])
	 by server1.messagingengine.com (Cyrus v2.3-alpha) with LMTPA;
	 Sun, 29 Jan 2006 15:36:50 -0500
X-Sieve: CMU Sieve 2.3
X-Resolved-to: jimdigriz@imapmail.org
X-Delivered-to: jimdigriz@imapmail.org
X-Mail-from: ferriste@libero.it
Received: from mail.just-the-name.co.uk (just-the-name.co.uk [213.162.97.161])
	by mx4.messagingengine.com (Postfix) with ESMTP id F22D997
	for <jimdigriz@imapmail.org>; Sun, 29 Jan 2006 15:36:45 -0500 (EST)
Received: from smtp6.libero.it (smtp6.libero.it [193.70.192.59])
	by mail.just-the-name.co.uk (Postfix) with ESMTP id 5D0C040598D
	for <alex@digriz.org.uk>; Sun, 29 Jan 2006 20:36:43 +0000 (GMT)
Received: from localhost (172.16.1.74) by smtp6.libero.it (7.0.027-DD01)
        id 439D919303A37C57 for alex@digriz.org.uk; Sun, 29 Jan 2006 21:35:41 +0100
Received: from smtp2.libero.it ([172.16.1.97])
 by localhost (asav16.libero.it [193.70.193.3]) (amavisd-new, port 10024)
 with ESMTP id 02282-17-10 for <alex@digriz.org.uk>;
 Sun, 29 Jan 2006 21:35:40 +0100 (CET)
Received: from libero.it (172.16.1.110) by smtp2.libero.it (7.0.027-DD01)
        id 431C3B200181EEDB for alex@digriz.org.uk; Sun, 29 Jan 2006 21:35:40 +0100
Date: Sun, 29 Jan 2006 21:35:40 +0100
Message-Id: <ITVFVG$9F861C6C3509DC9C2BC443FC94A4B7B2@libero.it>
Subject: Re: Bug in conservative governor?
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
From: "stefano ferri" <ferriste@libero.it>
To: "alex" <alex@digriz.org.uk>
X-XaM3-API-Version: 4.3 (R1) (B3pl11)
X-SenderIP: 82.51.2.225
X-Scanned: with antispam and antivirus automated system at libero.it
Content-Length: 1009
Lines: 19

Hi, don't worry :-) I hope not to disturb contacting you directly by emai=
l instead of open a bug on bugzilla, if you think it's better I'll open i=
t. And sorry for the errors, but my english is not too good!
I've not tried to recompile because I didn't know if it could be dangerou=
s for the hardware, now I'll try.
I will send you an e-mail as soon as I have some news!
Can I ask you just a thing? How can I know the latency transition  time o=
f my athlon xp-m 2800+? It is necessary to write and compile a code that =
uses cpufreq or there is something in /sys that I can read? The minimum s=
ampling rate for my processor (used by ondemand) is quite high, 0.1 secon=
ds... I don't know if this depends by the athlon family, but I've seen in=
 various forum on the internet that people can set the sampling rate to 1=
000, 0.001 seconds, when I can use a minimum of 99500, 0.1 seconds :-( I =
hoped that a governor in kernel space was faster, but maybe is a problem =
of my laptop...
Thanks!
Stefano


Date: Sun, 29 Jan 2006 19:08:44 +0000
From: Alexander Clouter <alex@digriz.org.uk>
To: stefano ferri <ferriste@libero.it>
Subject: Re: Bug in conservative governor?
Message-ID: <20060129190844.GD4005@inskipp.digriz.org.uk>
References: <ITODKD$AB9003C0C7E167A2B13A55F4CC420ABF@libero.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <ITODKD$AB9003C0C7E167A2B13A55F4CC420ABF@libero.it>
Return-Path: <alex@digriz.org.uk>
Organization: diGriz
X-URL: http://www.digriz.org.uk/
User-Agent: Mutt/1.5.11
Status: RO

Hi Stefano,

Sorry for the rather late reply.

stefano ferri <ferriste@libero.it> [20060126 02:02:37 +0100]:
>
> [snipped woes]
>
> with such values the ondemand governor can work fine. You can observe that
> the sampling_rate min of conservative is exactly 100 times greater than
> ondemand. Looking at the kernel source I've found this:
>
> file cpufreq_conservative.c , line 58
> #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(100000)
>
> file cpufreq_ondemand.c , line 53
> #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(1000)
>
> the constant defined in the first file is exactly 100 times greater than
> that defined in cpufreq_ondemand.c . This is normal or could be this the
> problem? Or is it caused by my hardware? I think I've loaded all necessary
> modules to make these governors work.
>
Yep, I remember doing that a long time back when I knew no better. :-/  I
thought I had removed it.  What I plan on doing is doing a diff between
ondemand and conservative and remove most of the differences, making ondemand
the base.

I really have done a bad job of it :(  Did you recompile the module with
'#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER  (1000)' in conservative?  Did
it fix things?

I'll get intouch with you once I have some patches....hopefully soon.

Cheers

Alex

--=20
 ______________________________
< Don't get mad, get interest. >
 ------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Return-Path: <ferriste@libero.it>
Received: from mx3.internal (mx3.internal [10.202.2.202])
	 by server1.messagingengine.com (Cyrus v2.3-alpha) with LMTPA;
	 Sun, 29 Jan 2006 17:25:15 -0500
X-Sieve: CMU Sieve 2.3
X-Resolved-to: jimdigriz@imapmail.org
X-Delivered-to: jimdigriz@imapmail.org
X-Mail-from: ferriste@libero.it
Received: from mail.just-the-name.co.uk (just-the-name.co.uk [213.162.97.161])
	by mx3.messagingengine.com (Postfix) with ESMTP id 5BE80121
	for <jimdigriz@imapmail.org>; Sun, 29 Jan 2006 17:25:04 -0500 (EST)
Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52])
	by mail.just-the-name.co.uk (Postfix) with ESMTP id 8D945404DF9
	for <alex@digriz.org.uk>; Sun, 29 Jan 2006 22:25:08 +0000 (GMT)
Received: from localhost (172.16.1.17) by smtp2.libero.it (7.0.027-DD01)
        id 439D906903796764 for alex@digriz.org.uk; Sun, 29 Jan 2006 23:24:18 +0100
Received: from smtp0.libero.it ([172.16.1.76])
 by localhost (asav12.libero.it [193.70.192.95]) (amavisd-new, port 10024)
 with ESMTP id 15566-11-12 for <alex@digriz.org.uk>;
 Sun, 29 Jan 2006 23:24:18 +0100 (CET)
Received: from libero.it (172.16.1.107) by smtp0.libero.it (7.0.027-DD01)
        id 439064B4008CEFE6 for alex@digriz.org.uk; Sun, 29 Jan 2006 23:24:18 +0100
Date: Sun, 29 Jan 2006 23:24:17 +0100
Message-Id: <ITVKWH$41012EE7981FB33E1C6510FC70CE9574@libero.it>
Subject: It works!
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
From: "stefano ferri" <ferriste@libero.it>
To: "alex" <alex@digriz.org.uk>
X-XaM3-API-Version: 4.3 (R1) (B3pl11)
X-SenderIP: 82.51.2.225
X-Scanned: with antispam and antivirus automated system at libero.it
Content-Length: 951
Lines: 18

Hi, I've just recompiled the module and it seems to work :-) I've changed=
 to 1000 the DEF_SAMPLING_RATE_LATENCY_MULTIPLIER constant, and now I obt=
ain the same values of the sampling rate of ondemand, both min and max. S=
orry because I asked you before trying by myself...
A look at the trans_table of cpufreq shows lots of transitions from lower=
 to higher frequencies in a continuos way, so it really works.
Only a thing maybe is different from ondemand, but it could be a wrong im=
pression: using the default value of the sampling rate that conservative =
sets (199000, the same of ondemand) the system is apparently slower than =
when ondemand is set as governor. This difference seems to disappear sett=
ing the sampling rate to the minimum (99500). But maybe it works fine and=
 it is my impression that is wrong...
I hope this can be useful to fix the problem, now I will test it and I wi=
ll tell you if there are news.

Cheers
Stefano



[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

Re: [Bug 8081] Conservative governor sets wrong and too high sampling rates

[stefano ferri]

> So now, if I have a default sampling rate of 199000, the min will be 19900... good

Oops.. wrong calculus. With the original code of the kernel default is 1990000, min with your patch will be 1/10, so 199000. Could you please align the min values with that of ondemand? (for my processor is 99500). It should be 1/20 of the default, and the min sampling rate that one can set would be about 1/10 of second.

Thanks
Stefano



------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada28eb07

[Bug 8081] Conservative governor sets wrong and too high sampling rates

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8081


protasnb@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex-kernel@digriz.org.uk




-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8081] Conservative governor sets wrong and too high sampling rates

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8081


protasnb@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |protasnb@gmail.com,
                   |                            |venkatesh.pallipadi@intel.co
                   |                            |m




------- Comment #2 from protasnb@gmail.com  2007-06-20 17:16 -------
This patch needs a review, adding CCs.
Thanks.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8081] Conservative governor sets wrong and too high sampling rates

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8081


cheetah-kbt@fastcat.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cheetah-kbt@fastcat.org




------- Comment #3 from cheetah-kbt@fastcat.org  2007-08-17 15:48 -------
I was trying to figure out why the conservative governor didn't seem to work on
my amd64 system, and ran across this bug and some other info.

I think that 10 * latency bit for the default sampling rate was deliberate,
since it was introduced as a standalone patch some time ago:
http://osdir.com/ml/kernel.cpufreq/2006-03/msg00048.html

However, that patch neglected to make a corresponding change to the rules for
the minimum sampling rate.

The result is that, on my amd64 system, the default sampling rate is 12.4
seconds, and the fastest rate is 6.2 seconds.

My CPU (athlon64 x2 4400) has speeds of 1000, 1800, 2000, and 2200 MHz
available to cpufreq.  With the defaults in the conservative governor then, it
will take it 99.2 seconds at full load to decide to notch it up from 1000 to
1800MHz (8 sampling rates each stepping the target speed by 100MHz).  This
calculation matches with some empirical observations I did.

I see two fixes that should be made from this:

1) The MIN_SAMPLING_RATE_RATIO define should be changed from 2 to 20, to match
the 10x change in the default sampling rate.  This would at least allow saner
configurations to be put in place by hand.

2) Instead of stepping the target frequency by a mythical 5% that probably
cannot be satisified by hardware, shouldn't it just step it up or down one
entry in the available frequencies table?


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8081] Conservative governor sets wrong and too high sampling rates

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8081


alex-kernel@digriz.org.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|cpufreq@www.linux.org.uk    |alex-kernel@digriz.org.uk
             Status|NEW                         |ASSIGNED




------- Comment #4 from alex-kernel@digriz.org.uk  2007-08-18 01:28 -------
(In reply to comment #3)
> 
> I think that 10 * latency bit for the default sampling rate was deliberate,
> since it was introduced as a standalone patch some time ago:
> http://osdir.com/ml/kernel.cpufreq/2006-03/msg00048.html
> 
Yes it was, the idea was to prevent the governor being as trigger happy as
ondemand; without it you would go from [min-freq]->[max-freq] in about 0.5
seconds :)

Stefano has been bugging me about this for ages but keeps wanting me just to
blat def_sampling_rate to what it used to be when I forked conservative from
ondemand.  It was my bad to not deal with this problem eariler.

> However, that patch neglected to make a corresponding change to the rules for
> the minimum sampling rate.
> 
> The result is that, on my amd64 system, the default sampling rate is 12.4
> seconds, and the fastest rate is 6.2 seconds.
> 
> My CPU (athlon64 x2 4400) has speeds of 1000, 1800, 2000, and 2200 MHz
> available to cpufreq.  With the defaults in the conservative governor then, it
> will take it 99.2 seconds at full load to decide to notch it up from 1000 to
> 1800MHz (8 sampling rates each stepping the target speed by 100MHz).  This
> calculation matches with some empirical observations I did.
> 
> I see two fixes that should be made from this:
> 
> 1) The MIN_SAMPLING_RATE_RATIO define should be changed from 2 to 20, to match
> the 10x change in the default sampling rate.  This would at least allow saner
> configurations to be put in place by hand.
> 
> 2) Instead of stepping the target frequency by a mythical 5% that probably
> cannot be satisified by hardware, shouldn't it just step it up or down one
> entry in the available frequencies table?
> 
The mythical 5% is there try and produce a result that is more like a smooth
change through speed.  It was done, this was the plan at least, so that in a
fixed time period and at full load on any machine the governor would move from
the minimum to highest clock speed.  Obviously this is not happening so it is
back to the drawing board.

It is not simple to just pull the frequencies and step through those, it was
beyond my understanding of C and the kernel (I think I vaguely recall someone
back in the midst's of time saying this was a Bad Idea and not possible anyway)
to import them into the governor besides the final result of either stepping in
5% incremements or the actually frequencies themselves is the same; I would
just say in the latter case it makes it easier to true to bring in a 'constant
time' element.

Anyway, now I know there are at least two folks suffering this problem I'll
look into fixing it but it might be a month before something is produced; Real
Life has hit me pretty hard with work and finding a place to live.

Cheers

Alex


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.