On 27-10-16, 18:41, Patrick Bellasi wrote: > +This last requirement is especially important if we consider that schedutil can > +potentially replace all currently available CPUFreq policies. Since schedutil > +is event based, as opposed to the sampling driven governors, it is already more > +responsive at selecting the optimal OPP to run tasks allocated to a CPU. I am not sure if I follow this paragraph. All the governors follow the same basic rules now. They are all event driven (events from scheduler), but they function only after a certain sampling period is finished. Isn't this the case ? > +SchedTune exposes a simple user-space interface with a single power-performance > +tunable: > + > + /proc/sys/kernel/sched_cfs_boost > + > +This permits expressing a boost value as an integer in the range [0..100]. > + > +A value of 0 (default) for a CFS task means that schedutil will attempt > +to match compute capacity of the CPU where the task is scheduled to > +match its current utilization with a few spare cycles left. A value of > +100 means that schedutil will select the highest available OPP. > + > +The range between 0 and 100 can be set to satisfy other scenarios suitably. > +For example to satisfy interactive response or depending on other system events > +(battery level, thermal status, etc). Earlier section said that schedutil+schedtune can replace all earlier governors. How will schedutil behave like powersave governor with schedtune? I was expecting the possible values of sched_cfs_boost to be in the range -100 to 100, where -100 will make it powersave, +100 will make it performance and 0 will not make any changes. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
