[lkml]   [2011]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection
    > I think there are other problems too, related to saving and restoring
    > of pm_idle pointer. For example, cpuidle itself saves current value
    > of pm_idle, flips it and then restores the saved value. There is
    > no guarantee that the saved function still exists. APM does exact
    > same thing (though it may not be used these days).
    > The problem also is that a number of architectures have copied the
    > same design based on pm_idle; so its spreading.

    pm_idle is a primitive design yes, but I think the issue
    with pm_idle is a theoretical one, at least on x86;
    as there isn't any other code scribbling on pm_idle
    in practice. So this is clean-up, rather than bug-fix work...

    > > It isn't immediately clear to me that all of these options
    > > need to be preserved.
    > So what do you suggest can be removed?

    I sent a series of small patches yesterday to get the ball rolling...

    I think the xen thing can go away.

    I proposed that APM be removed entirely,
    but that will take a few releases to conclude....

    > > Are we suggesting that x86 must always build with cpuidle?
    > > I'm sure that somebody someplace will object to that.
    > Arjan argued that since almost everyone today runs cpuidle
    > it may be best to include it in the kernel
    > ( But yes, we agreed
    > that we would have to make cpuidle lighter incrementally.
    > Making ladder governor optional could be one way for example.

    ladder is already optional.

    -Len Brown, Intel Open Source Technology Center

     \ /
      Last update: 2011-03-25 08:09    [W:0.021 / U:55.516 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site