* Rafael J. Wysocki <r...@sisk.pl> [2009-08-09 15:22:02]: > On Sunday 09 August 2009, Pavel Machek wrote: > > Hi! > > > > > > Also, approaches such as [1] can make use of this > > > > extended infrastructure instead of putting the CPU to an arbitrary > > > > C-state > > > > when it is offlined, thereby providing the system administrator a rope > > > > to hang > > > > himself with should he feel the need to do so. > > > I didn't see the reason why administrator needs to know which state > > > offline cpu > > > should stay. Don't know about powerpc side, but in x86 side, it appears > > > deepest > > > C-state is already preferred. > > > > > > > Agreed, deepest c-state is always best, there's no need to make it > > configurable. > > Unless it doesn't work.
Yes, this is one of the reason. Kernel will know about the deepest sleep state and any restrictions and should set that as default in the preferred_offline state. End-users and sys-admins need not change it, default will be the deepest sleep state supported and allowed by the system which may be different than the one supported by the processor. This framework could allow the default to be set easily by other userspace tools. These restrictions apply to cpuidle governor as well, hence at some level both these subsystems should be in sync. As described in this patch series, the meaning of offline cpu is different in a virtualized system and this framework provides flexibility of choice there. Platforms today do have a choice on what state an offline cpu should reside, this framework is one of the possible methods to exploit that choice and not restrict it due to lack of OS flexibility. --Vaidy _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
