[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.019 / U:47.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site