[lkml]   [2003]   [Oct]   [22]   [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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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