Messages in this thread | | | Date | Thu, 16 Aug 2012 14:05:45 +0600 | Subject | Re: [discussion]sched: a rough proposal to enable power saving in scheduler | From | Rakib Mullick <> |
| |
On 8/16/12, Alex Shi <alex.shi@intel.com> wrote: > On 08/15/2012 10:24 PM, Rakib Mullick wrote: > >> On 8/13/12, Alex Shi <alex.shi@intel.com> wrote: >>> Since there is no power saving consideration in scheduler CFS, I has a >>> very rough idea for enabling a new power saving schema in CFS. >>> >>> It bases on the following assumption: >>> 1, If there are many task crowd in system, just let few domain cpus >>> running and let other cpus idle can not save power. Let all cpu take the >>> load, finish tasks early, and then get into idle. will save more power >>> and have better user experience. >>> >> This assumption indirectly point towards the scheme when performance >> is enabled, isn't it? Cause you're trying to spread the load equally >> amongst all the CPUs. > > > It is. > Okay, then what would be the default mechanism? Performance or powersavings ? Your proposal deals with performance and power saving, but there should be a default mechanism too, what that default mechanism would be? Shouldn't performance be the default one and discard checking for performance?
>> >>> >>> select_task_rq_fair() >>> { > > int powersaving = 0; > >>> for_each_domain(cpu, tmp) { >>> if (policy == power && tmp_has_capacity && >>> tmp->flags & sd_flag) { >>> sd = tmp; >>> //It is fine to got cpu in the domain > > powersaving = 1; > >>> break; >>> } >>> } >>> >>> while(sd) { > if (policy == power && powersaving == 1) >>> find_busiest_and_capable_group() >> >> I'm not sure what find_busiest_and_capable_group() would really be, it >> seems it'll find the busiest and capable group, but isn't it a >> conflict with the first assumption you proposed on your proposal? > > > This pseudo code missed a power saving workable flag , adding it into > above code should solved your concern. > I think I should take a look at this one when it'll be prepared for RFC.
Thanks, Rakib.
| |