Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 22 Oct 2003 09:18:57 +0200 | From | Arjan van de Ven <> | Subject | Re: [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 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/
| ![\](/images/icornerr.gif) |