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