> > We'd like to ship the forced-idle thread as a self-contained driver, > > if possilbe. Because that would enable us to easily back-port it > > to some enterprise releases that want the feature. So if we can > > implement this such that it is functional with existing scheduler > > facilities, that would be get us by. If the scheduler evolves > > and provides a more optimal mechanism in the future, then that is > > great, as long as we don't have to wait for that to provide > > the basic version of the feature. > > I don't think we should ever merge anything because of backports for > stale kernels. > > If you want it in enterprise stuff all you need is something upstream, > and that something should be the scheduler driven bits. Peter, I'm glad that you agree that the forced-idle goals are worth-while, and I'm delighted that you offer the scheduler to implement a solution to this problem. When will we see a scheduler API that we can call from our ACPI notification driver to create idle-time on a busy system? As you've seen in the driver, we are notified simply of the total number of hardware threads to keep running. Linux has full freedom in selecting (and even moving) which processors are idled. thanks, -Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
