Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755292AbbKWR7G (ORCPT ); Mon, 23 Nov 2015 12:59:06 -0500 Received: from mga03.intel.com ([134.134.136.65]:30247 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753617AbbKWR7E (ORCPT ); Mon, 23 Nov 2015 12:59:04 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,338,1444719600"; d="scan'208";a="692725500" Date: Mon, 23 Nov 2015 09:59:02 -0800 From: Jacob Pan To: Morten Rasmussen Cc: Arjan van de Ven , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , John Stultz , LKML , Srinivas Pandruvada , Len Brown , Rafael Wysocki , Eduardo Valentin , Paul Turner , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH 3/4] sched: introduce synchronized idle injection Message-ID: <20151123095902.6a3af628@yairi> In-Reply-To: <20151119172405.GA798@e105550-lin.cambridge.arm.com> References: <1447444387-23525-1-git-send-email-jacob.jun.pan@linux.intel.com> <1447444387-23525-4-git-send-email-jacob.jun.pan@linux.intel.com> <20151118154457.GD30184@e105550-lin.cambridge.arm.com> <564C9E93.8030901@linux.intel.com> <20151119172405.GA798@e105550-lin.cambridge.arm.com> Organization: OTC X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1825 Lines: 37 On Thu, 19 Nov 2015 17:24:07 +0000 Morten Rasmussen wrote: > I could see this technique being useful within the SoC as well. > Synchronized idle injection on all cpus in a cluster would allow us to > reach cluster idle states where resources shared within the cluster > can be gated or powered off as well. But yes, shutting down > everything is more efficient if you are en serious trouble. > > I was hoping this could be a good alternative to hotplugging cpus out > for thermal management in non-critical situations, but it isn't that > appealing if you have to throttle all the cpus. I would consider it an > emergency-only mechanism (as in emergency brake) that isn't really > suitable for normal thermal management. In which case: Does this sort > of mechanism belong in the scheduler code? I would think this is not an emergency-only mechanism. I know shutting down all CPUs at the same time sounds bad but here are advantage of having this in the scheduler in that we can still have certain QoS. e.g. we yeild softirq, RT. etc. There are other workload info readily available in the scheduler to better use this knob. e.g. sync with other input timers such as media. For normal thermal conditions, Skylake for example, the max efficient frequency is ~900MHz. If thermal restriction happens (e.g. you want to do fanless), would you like to lose energy efficiency by further lowering frequency to 500Mhz? or do idle injection and take 5ms latency for normal tasks? Idle injection gives you near linear performance-power scaling. Thanks, Jacob -- 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/