Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755613AbbKDGHB (ORCPT ); Wed, 4 Nov 2015 01:07:01 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:35428 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754996AbbKDGG7 (ORCPT ); Wed, 4 Nov 2015 01:06:59 -0500 Date: Tue, 3 Nov 2015 22:06:55 -0800 From: Eduardo Valentin To: Jacob Pan Cc: Peter Zijlstra , Thomas Gleixner , LKML , Arjan van de Ven , Paul Turner , Len Brown , Srinivas Pandruvada , Tim Chen , Andi Kleen , Rafael Wysocki Subject: Re: [RFC PATCH 0/3] CFS idle injection Message-ID: <20151104060654.GC8850@localhost.localdomain> References: <1446509428-5616-1-git-send-email-jacob.jun.pan@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1446509428-5616-1-git-send-email-jacob.jun.pan@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3042 Lines: 81 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. Was there any particular reason you dropped the cooling device support? 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/ -- 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/