lkml.org 
[lkml]   [2003]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver
Date
From


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...
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.032 / U:0.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site