[PATCH] cpuidle: improve governor Kconfig options

Rafael J. Wysocki rjw at sisk.pl
Tue May 28 17:26:44 EDT 2013


On Tuesday, May 28, 2013 03:23:37 PM Daniel Lezcano wrote:
> On 05/28/2013 02:42 PM, Rafael J. Wysocki wrote:
> > On Tuesday, May 28, 2013 02:23:00 PM Daniel Lezcano wrote:
> >> On 05/28/2013 01:46 PM, Rafael J. Wysocki wrote:
> >>> On Monday, May 27, 2013 11:00:58 PM Daniel Lezcano wrote:
> >>>> Each governor is suitable for different kernel configurations: the menu
> >>>> governor suits better for a tickless system, while the ladder governor fits
> >>>> better for a periodic timer tick system.
> >>>>
> >>>> The Kconfig does not allow to [un]select a governor, thus both are compiled in
> >>>> the kernel but the init order makes the menu governor to be the last one to be
> >>>> registered, so becoming the default. The only way to switch back to the ladder
> >>>> governor is to enable the sysfs governor switch in the kernel command line.
> >>>>
> >>>> Because it seems nobody complained about this, the menu governor is used by
> >>>> default most of the time on the system, having both governors is not really
> >>>> necessary on a tickless system but there isn't a config option to disable one
> >>>> or another governor.
> >>>>
> >>>> Create a submenu for cpuidle and add a label for each governor, so we can see
> >>>> the option in the menu config and enable/disable it.
> >>>>
> >>>> The governors will be enabled depending on the CONFIG_NO_HZ option:
> >>>>  - If CONFIG_NO_HZ is set, then the menu governor is selected and the ladder
> >>>>    governor is optional, defaulting to 'no'
> >>>
> >>> Why not defaulting to 'yes'?  That'd be backwards compatible, wouldn't it?
> >>
> >> Yes, that wouldn't be backward compatible but who wants the ladder
> >> governor which is less efficient with a tickless system ?
> > 
> > I don't know and this isn't the right question to ask I think.
> > 
> > You need to ask who uses the ladder governor with CONFIG_NO_HZ and you need to
> > avoid making changes that aren't backwards compatible if you don't know the
> > answer (which I'm pretty sure is the case).
> > 
> > I'd prefer to default to 'yes' to start with and then to change the
> > default to 'no' after a couple of cycles, possibly.
> > 
> >>>>  - If CONFIG_NO_HZ is not set, then the ladder governor is selected and the
> >>>>    menu governor is optional, defaulting to 'no'
> >>>
> >>> Are you sure this is not going to introduce regressions with CONFIG_NO_HZ
> >>> unset?
> >>
> >> Yes, a system configured with a periodic tick will use the ladder
> >> instead of the menu governor (which is less efficient on this
> >> configuration).
> > 
> > Well, "less efficient" meaning what exactly?  Less power-efficient or less
> > efficient performance-wise?
> 
> less power efficient.

I thought so, but that's really important, because some people *do* care about
performance.  In the context of changes like this one we always need to talk
about both power and performance.  For example, when you're saying that
changing something may lead to better energy saving behavior, you should also
say what the impact of that change on performance is going to be.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.



More information about the linux-arm-kernel mailing list