Messages in this thread | | | Subject | Re: [RFC PATCH 0/3] CFS idle injection | From | Srinivas Pandruvada <> | Date | Wed, 04 Nov 2015 09:05:52 -0800 |
| |
On Wed, 2015-11-04 at 08:58 -0800, Jacob Pan wrote: > On Tue, 3 Nov 2015 22:06:55 -0800 > Eduardo Valentin <edubezval@gmail.com> wrote: > > > Hello Jacob, > > > > On Mon, Nov 02, 2015 at 04:10:25PM -0800, Jacob Pan wrote: > > > Hi Peter and all, > > > > > > A while ago, we had discussion about how powerclamp is broken in the > > > sense of turning off idle ticks in the forced idle period. > > > https://lkml.org/lkml/2014/12/18/369 > > > > > > It was suggested to replace the current kthread play idle loop with > > > a timer based runqueue throttling scheme. I finally got around to > > > implement this and code is much simpler. I also have good test > > > results in terms of efficiency, scalability, etc. > > > http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Japan_2015_idle_injection1_0.pdf > > > slide #18+ shows the data on client and server. > > > > > > I have two choices for this code: > > > 1) be part of existing powerclamp driver but require exporting some > > > sched APIs. > > > 2) be part of sched since the genernal rule applies when it comes > > > down to sycnhronized idle time for best power savings. > > > > > > The patches below are for #2. There is a known problem with LOW RES > > > timer mode that I am working on. But I am hoping to get review > > > earlier. > > > > > > > I also like #2 too. Specially now that it is not limited to a specific > > platform. One question though, could you still keep the cooling device > > support of it? In some systems, it might make sense to enable / > > disable idle injections based on temperature. > > > One of the key difference between 1 and 2 is that #2 is open loop > control, since we don't have CPU c-states info baked into scheduler. To > close the loop, perhaps we can export some internal APIs to the thermal > subsystem then the thermal governors can pick the condition to inject > idle. > > Was there any particular reason you dropped the cooling device > > support? > > > I did sysctl instead of thermal sysfs to conform the rest of the sched > tuning knobs. We could also have a proxy cooling device to call > internal APIs mentioned above. I think we should have cooling device as we are already using this cooling device. Once it pass RFC stage,I think we should consider add this. Thanks, Srinivas > > Another reason is that, I intend to extend beyond thermal. Where we can > consolidate/sync idle work in semi-active and balanced workload. > > Thanks for the suggestions, > > Jacob > > BR, > > > > Eduardo Valentin > > > > > > > We are entering a very power limited environment on client side, > > > frequency scaling can only be efficient at certain range. e.g. on > > > SKL, upto ~900MHz, anything below, it is increasingly more > > > efficient to do C-states insertion if coordinated. > > > > > > Looking forward, there are use case beyond thermal/power capping. I > > > think we can consolidate ballanced partial busy workload that are > > > evenly distributed among CPUs. > > > > > > Please let me know what you think. > > > > > > Thanks, > > > > > > > > > Jacob Pan (3): > > > ktime: add a roundup function > > > timer: relax tick stop in idle entry > > > sched: introduce synchronized idle injection > > > > > > include/linux/ktime.h | 10 ++ > > > include/linux/sched.h | 12 ++ > > > include/linux/sched/sysctl.h | 5 + > > > include/trace/events/sched.h | 23 +++ > > > init/Kconfig | 8 + > > > kernel/sched/fair.c | 345 > > > +++++++++++++++++++++++++++++++++++++++++++ > > > kernel/sched/sched.h | 3 + kernel/sysctl.c > > > | 20 +++ kernel/time/tick-sched.c | 2 +- > > > 9 files changed, 427 insertions(+), 1 deletion(-) > > > > > > -- > > > 1.9.1 > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe > > > linux-kernel" in the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > [Jacob Pan]
| |