RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Nakajima, Jun]

> 
> it's all nice code and such, but I still wonder why this can't be done
> by a userland policy daemon. The 2.6 kernel has the infrastructure to
> give very detailed information to userspace (eg top etc) about idle
> percentages...... I didn't see anything in this driver that couldn't
be
> done from userspace.
> 

It's about the frequency of the feedback loop. As we have much lower
latency with P-state transitions, the sampling time can be order of
millisecond (or shorter if meaningful). A userland daemon can have a
high-level policy (preferences, or set of parameters), but it cannot be
part of the real feedback loop. If we combine P-state transitions and
deeper C-state transitions, the situation is worse with a userland
daemon.

	Jun

RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Nakajima, Jun]

> 
> it's all nice code and such, but I still wonder why this can't be done
> by a userland policy daemon. The 2.6 kernel has the infrastructure to
> give very detailed information to userspace (eg top etc) about idle
> percentages...... I didn't see anything in this driver that couldn't
be
> done from userspace.
> 

It's about the frequency of the feedback loop. As we have much lower
latency with P-state transitions, the sampling time can be order of
millisecond (or shorter if meaningful). A userland daemon can have a
high-level policy (preferences, or set of parameters), but it cannot be
part of the real feedback loop. If we combine P-state transitions and
deeper C-state transitions, the situation is worse with a userland
daemon.

	Jun

RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Carl Thompson]

Quoting "Nakajima, Jun" <jun.nakajima@intel.com>:

> ...

> It's about the frequency of the feedback loop. As we have much lower
> latency with P-state transitions, the sampling time can be order of
> millisecond (or shorter if meaningful). A userland daemon can have a
> high-level policy (preferences, or set of parameters), but it cannot be
> part of the real feedback loop. If we combine P-state transitions and
> deeper C-state transitions, the situation is worse with a userland
> daemon.

You are making the assumption that a higher polling frequency (we'll say
1ms) is in general better than a lower frequency (we'll say 1s).  I submit
that it is not.

If I hit a key on my keyboard and your high frequency loop increases CPU
speed so that my word processor displays the letter 0.01s faster, is that
really beneficial?  If a window renders in 0.2s seconds instead of 0.3s is
that a difference I am going to notice?

On the other hand, if I do a kernel compile and it is done 0.999s faster
with the higher frequency loop, am I going to miss that second over such a
long duration?  (In reality, the compile with the high-frequency loop would
probably take longer unless it has near zero overhead).

In my opinion it is wasteful to increase CPU speed unless there is a longer
term need for it.

> 	Jun

Carl Thompson

RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Carl Thompson]

Quoting "Nakajima, Jun" <jun.nakajima@intel.com>:

> ...

> It's about the frequency of the feedback loop. As we have much lower
> latency with P-state transitions, the sampling time can be order of
> millisecond (or shorter if meaningful). A userland daemon can have a
> high-level policy (preferences, or set of parameters), but it cannot be
> part of the real feedback loop. If we combine P-state transitions and
> deeper C-state transitions, the situation is worse with a userland
> daemon.

You are making the assumption that a higher polling frequency (we'll say
1ms) is in general better than a lower frequency (we'll say 1s).  I submit
that it is not.

If I hit a key on my keyboard and your high frequency loop increases CPU
speed so that my word processor displays the letter 0.01s faster, is that
really beneficial?  If a window renders in 0.2s seconds instead of 0.3s is
that a difference I am going to notice?

On the other hand, if I do a kernel compile and it is done 0.999s faster
with the higher frequency loop, am I going to miss that second over such a
long duration?  (In reality, the compile with the high-frequency loop would
probably take longer unless it has near zero overhead).

In my opinion it is wasteful to increase CPU speed unless there is a longer
term need for it.

> 	Jun

Carl Thompson

Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Dominik Brodowski]

On Tue, Oct 21, 2003 at 12:55:55PM -0700, Carl Thompson wrote:
> Quoting "Nakajima, Jun" <jun.nakajima@intel.com>:
> 
> > ...
> 
> > It's about the frequency of the feedback loop. As we have much lower
> > latency with P-state transitions, the sampling time can be order of
> > millisecond (or shorter if meaningful). A userland daemon can have a
> > high-level policy (preferences, or set of parameters), but it cannot be
> > part of the real feedback loop. If we combine P-state transitions and
> > deeper C-state transitions, the situation is worse with a userland
> > daemon.
> 
> You are making the assumption that a higher polling frequency (we'll say
> 1ms) is in general better than a lower frequency (we'll say 1s).  I submit
> that it is not.
> 
> If I hit a key on my keyboard and your high frequency loop increases CPU
> speed so that my word processor displays the letter 0.01s faster, is that
> really beneficial?  If a window renders in 0.2s seconds instead of 0.3s is
> that a difference I am going to notice?
> 
> On the other hand, if I do a kernel compile and it is done 0.999s faster
> with the higher frequency loop, am I going to miss that second over such a
> long duration?  (In reality, the compile with the high-frequency loop would
> probably take longer unless it has near zero overhead).
> 
> In my opinion it is wasteful to increase CPU speed unless there is a longer
> term need for it.

Different needs, different opinions, different governors...

	Dominik

Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Arjan van de Ven]

On Tue, Oct 21, 2003 at 08:47:51AM -0700, Nakajima, Jun wrote:
> > 
> > it's all nice code and such, but I still wonder why this can't be done
> > by a userland policy daemon. The 2.6 kernel has the infrastructure to
> > give very detailed information to userspace (eg top etc) about idle
> > percentages...... I didn't see anything in this driver that couldn't
> be
> > done from userspace.
> > 
> 
> It's about the frequency of the feedback loop. As we have much lower
> latency with P-state transitions, the sampling time can be order of
> millisecond (or shorter if meaningful). A userland daemon can have a
> high-level policy (preferences, or set of parameters), but it cannot be
> part of the real feedback loop. If we combine P-state transitions and
> deeper C-state transitions, the situation is worse with a userland
> daemon.


As I said the CURRENT code doesn't seem to do that. I can see the use of
in kernel hooks in to thigs; for example the scheduler could do an upcall
to the cpufreq core if a task uses it's timeslice completely (which would
be a sign that things need to go to a higher speed). I'd be very
interested to see things like that.

Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Arjan van de Ven]

On Tue, Oct 21, 2003 at 08:47:51AM -0700, Nakajima, Jun wrote:
> > 
> > it's all nice code and such, but I still wonder why this can't be done
> > by a userland policy daemon. The 2.6 kernel has the infrastructure to
> > give very detailed information to userspace (eg top etc) about idle
> > percentages...... I didn't see anything in this driver that couldn't
> be
> > done from userspace.
> > 
> 
> It's about the frequency of the feedback loop. As we have much lower
> latency with P-state transitions, the sampling time can be order of
> millisecond (or shorter if meaningful). A userland daemon can have a
> high-level policy (preferences, or set of parameters), but it cannot be
> part of the real feedback loop. If we combine P-state transitions and
> deeper C-state transitions, the situation is worse with a userland
> daemon.


As I said the CURRENT code doesn't seem to do that. I can see the use of
in kernel hooks in to thigs; for example the scheduler could do an upcall
to the cpufreq core if a task uses it's timeslice completely (which would
be a sign that things need to go to a higher speed). I'd be very
interested to see things like that.

RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Pallipadi, Venkatesh]

We can have a userspace governor and take decisions using
top, /proc/interrupts etc. But issue is mostly the rate
at which we want to monitor. In kernel governor can afford
to do more frequent checks and use the low latency P-state 
change feature quite effectively.

The patch does take care of all kinds of loads, process or irq
as we look at the cpu idle time in kstat. However it waits until
scheduled work (schedule_work()) gets to run. As you say, 
another advantage of having this in kernel is, kernel has 
all the information to take such decisions quickly. At present,
The patch tries to keep this governor simple and cover the 
common cases. However, once we have the infrastructure in place,
further optimizations with more advanced things can be done 
based on actual performance data.

Thanks,
-Venkatesh

> -----Original Message-----
> From: Arjan van de Ven [mailto:arjanv@redhat.com] 
> Sent: Tuesday, October 21, 2003 1:39 AM
> To: Pallipadi, Venkatesh
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org; 
> linux-acpi; Mallick, Asit K; Nakajima, Jun; Dominik Brodowski
> Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates 
> to ACPIP-state driver
> 
> 
> On Tue, 2003-10-21 at 04:56, Pallipadi, Venkatesh wrote:
> > Patch 3/3: New dynamic cpufreq driver (called 
> > DemandBasedSwitch driver), which periodically monitors CPU 
> > usage and changes the CPU frequency based on the demand.
> 
> 
> it's all nice code and such, but I still wonder why this can't be done
> by a userland policy daemon. The 2.6 kernel has the infrastructure to
> give very detailed information to userspace (eg top etc) about idle
> percentages...... I didn't see anything in this driver that 
> couldn't be
> done from userspace.
> 
> Note that I'm not totally against doing some of this in the kernel; I
> can well see the point of say, detecting an IRQ overload and based on
> that, go to max speed in the kernel because it's a situation where
> userspace doesn't even run; but the patch as is doesn't do any such
> advanced things...
> 

RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver

[Pallipadi, Venkatesh]

We can have a userspace governor and take decisions using
top, /proc/interrupts etc. But issue is mostly the rate
at which we want to monitor. In kernel governor can afford
to do more frequent checks and use the low latency P-state 
change feature quite effectively.

The patch does take care of all kinds of loads, process or irq
as we look at the cpu idle time in kstat. However it waits until
scheduled work (schedule_work()) gets to run. As you say, 
another advantage of having this in kernel is, kernel has 
all the information to take such decisions quickly. At present,
The patch tries to keep this governor simple and cover the 
common cases. However, once we have the infrastructure in place,
further optimizations with more advanced things can be done 
based on actual performance data.

Thanks,
-Venkatesh

> -----Original Message-----
> From: Arjan van de Ven [mailto:arjanv@redhat.com] 
> Sent: Tuesday, October 21, 2003 1:39 AM
> To: Pallipadi, Venkatesh
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org; 
> linux-acpi; Mallick, Asit K; Nakajima, Jun; Dominik Brodowski
> Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates 
> to ACPIP-state driver
> 
> 
> On Tue, 2003-10-21 at 04:56, Pallipadi, Venkatesh wrote:
> > Patch 3/3: New dynamic cpufreq driver (called 
> > DemandBasedSwitch driver), which periodically monitors CPU 
> > usage and changes the CPU frequency based on the demand.
> 
> 
> it's all nice code and such, but I still wonder why this can't be done
> by a userland policy daemon. The 2.6 kernel has the infrastructure to
> give very detailed information to userspace (eg top etc) about idle
> percentages...... I didn't see anything in this driver that 
> couldn't be
> done from userspace.
> 
> Note that I'm not totally against doing some of this in the kernel; I
> can well see the point of say, detecting an IRQ overload and based on
> that, go to max speed in the kernel because it's a situation where
> userspace doesn't even run; but the patch as is doesn't do any such
> advanced things...
>