On 06/07/2014 03:25 PM, Pavel Machek wrote:
> Hi!
>
>> We just want to avoid the stupidity of dropping down the frequency to a
>> minimum
>> and then enduring a needless (and long) delay before ramping it up back
>> again.
>> So, let us simply carry forward the previous load - that is, let us
Hi!
> We just want to avoid the stupidity of dropping down the frequency to a
> minimum
> and then enduring a needless (and long) delay before ramping it up back again.
> So, let us simply carry forward the previous load - that is, let us just
> pretend
> that the 'load' for the current
Hi!
We just want to avoid the stupidity of dropping down the frequency to a
minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just
pretend
that the 'load' for the current time-window
On 06/07/2014 03:25 PM, Pavel Machek wrote:
Hi!
We just want to avoid the stupidity of dropping down the frequency to a
minimum
and then enduring a needless (and long) delay before ramping it up back
again.
So, let us simply carry forward the previous load - that is, let us just
On 06/03/2014 03:46 PM, Viresh Kumar wrote:
> On 3 June 2014 15:43, Srivatsa S. Bhat
> wrote:
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> index e1c6433..2597bbe 100644
>> --- a/drivers/cpufreq/cpufreq_governor.c
>> +++
On 3 June 2014 15:43, Srivatsa S. Bhat wrote:
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index e1c6433..2597bbe 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -36,14 +36,29 @@ void
On 06/03/2014 03:38 PM, Viresh Kumar wrote:
> On 3 June 2014 15:34, Srivatsa S. Bhat
> wrote:
>> Well, the method I used keeps the organization such that the code following
>> the comment does precisely what the comment says (i.e, get the sampling_rate,
>> fetch the multiplier, and then
On 3 June 2014 15:34, Srivatsa S. Bhat wrote:
> Well, the method I used keeps the organization such that the code following
> the comment does precisely what the comment says (i.e, get the sampling_rate,
> fetch the multiplier, and then multiply). So I feel it makes it easier to
> understand.
It
On 06/03/2014 03:09 PM, Viresh Kumar wrote:
> On 3 June 2014 15:02, Srivatsa S. Bhat
> wrote:
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> index e1c6433..3e8588f 100644
>> --- a/drivers/cpufreq/cpufreq_governor.c
>> +++
On 3 June 2014 15:02, Srivatsa S. Bhat wrote:
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index e1c6433..3e8588f 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -36,14 +36,29 @@ void
On 06/03/2014 01:48 PM, Viresh Kumar wrote:
> On 27 May 2014 02:23, Srivatsa S. Bhat
> wrote:
>
> Looks fine, some nits..
>
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> -void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
>> +void
On 27 May 2014 02:23, Srivatsa S. Bhat wrote:
Looks fine, some nits..
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> -void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
> +void dbs_check_cpu(struct dbs_data *dbs_data, int cpu,
> +
On 27 May 2014 02:23, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
Looks fine, some nits..
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
-void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
+void dbs_check_cpu(struct dbs_data *dbs_data,
On 06/03/2014 01:48 PM, Viresh Kumar wrote:
On 27 May 2014 02:23, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
wrote:
Looks fine, some nits..
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
-void dbs_check_cpu(struct dbs_data *dbs_data, int
On 3 June 2014 15:02, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index e1c6433..3e8588f 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -36,14
On 06/03/2014 03:09 PM, Viresh Kumar wrote:
On 3 June 2014 15:02, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
wrote:
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index e1c6433..3e8588f 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++
On 3 June 2014 15:34, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
Well, the method I used keeps the organization such that the code following
the comment does precisely what the comment says (i.e, get the sampling_rate,
fetch the multiplier, and then multiply). So I feel it makes
On 06/03/2014 03:38 PM, Viresh Kumar wrote:
On 3 June 2014 15:34, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
wrote:
Well, the method I used keeps the organization such that the code following
the comment does precisely what the comment says (i.e, get the sampling_rate,
fetch the
On 3 June 2014 15:43, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote:
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index e1c6433..2597bbe 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -36,14
On 06/03/2014 03:46 PM, Viresh Kumar wrote:
On 3 June 2014 15:43, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
wrote:
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index e1c6433..2597bbe 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++
On 06/03/2014 10:46 AM, Gautham R Shenoy wrote:
> On Mon, Jun 02, 2014 at 01:45:38PM +0530, Srivatsa S. Bhat wrote:
>> On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
>>> Hi,
>>>
>>> On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
>>>
>>> [..snip..]
Experimental
On Mon, Jun 02, 2014 at 01:45:38PM +0530, Srivatsa S. Bhat wrote:
> On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
> > Hi,
> >
> > On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
> >
> > [..snip..]
> >>
> >> Experimental results:
> >>
> >>
> >> I ran a
On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
> Hi,
>
> On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
>
> [..snip..]
>>
>> Experimental results:
>>
>>
>> I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
>> between its
Hi,
On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
[..snip..]
>
> Experimental results:
>
>
> I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
> between its execution such that its total utilization can be a user-defined
>
Hi,
On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
[..snip..]
Experimental results:
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say
On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
Hi,
On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
[..snip..]
Experimental results:
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its
On Mon, Jun 02, 2014 at 01:45:38PM +0530, Srivatsa S. Bhat wrote:
On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
Hi,
On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
[..snip..]
Experimental results:
I ran a modified version of ebizzy
On 06/03/2014 10:46 AM, Gautham R Shenoy wrote:
On Mon, Jun 02, 2014 at 01:45:38PM +0530, Srivatsa S. Bhat wrote:
On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
Hi,
On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
[..snip..]
Experimental results:
On 05/27/2014 04:57 AM, Rafael J. Wysocki wrote:
> Hi Srivatsa,
>
> On Tuesday, May 27, 2014 02:23:38 AM Srivatsa S. Bhat wrote:
>> Cpufreq governors like the ondemand governor calculate the load on the CPU
>> periodically by employing deferrable timers. A deferrable timer won't fire
>> if the
Hi Srivatsa,
On Tuesday, May 27, 2014 02:23:38 AM Srivatsa S. Bhat wrote:
> Cpufreq governors like the ondemand governor calculate the load on the CPU
> periodically by employing deferrable timers. A deferrable timer won't fire
> if the CPU is completely idle (and there are no other timers to be
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However,
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However,
Hi Srivatsa,
On Tuesday, May 27, 2014 02:23:38 AM Srivatsa S. Bhat wrote:
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be
On 05/27/2014 04:57 AM, Rafael J. Wysocki wrote:
Hi Srivatsa,
On Tuesday, May 27, 2014 02:23:38 AM Srivatsa S. Bhat wrote:
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is
34 matches
Mail list logo
