Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162350AbbKTJqJ (ORCPT ); Fri, 20 Nov 2015 04:46:09 -0500 Received: from www.linutronix.de ([62.245.132.108]:48057 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934343AbbKTJqG (ORCPT ); Fri, 20 Nov 2015 04:46:06 -0500 Date: Fri, 20 Nov 2015 10:45:14 +0100 (CET) From: Thomas Gleixner To: Peter Zijlstra cc: Morten Rasmussen , Arjan van de Ven , Jacob Pan , Ingo Molnar , John Stultz , LKML , Srinivas Pandruvada , Len Brown , Rafael Wysocki , Eduardo Valentin , Paul Turner Subject: Re: [PATCH 3/4] sched: introduce synchronized idle injection In-Reply-To: <20151119200906.GS3816@twins.programming.kicks-ass.net> Message-ID: 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> <20151119200906.GS3816@twins.programming.kicks-ass.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1233 Lines: 30 On Thu, 19 Nov 2015, Peter Zijlstra wrote: > On Thu, Nov 19, 2015 at 05:24:07PM +0000, Morten Rasmussen wrote: > > 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 prefer it not to be, but Thomas is very much opposed to teaching > the nohz code to 'work' on !idle threads. The whole concept of faking idle is simply crap. If you want to avoid that stuff in the scheduler, then create a mechanism which just defers the next timer interrupt for X milliseconds and does not any fiddling with NOHZ state and such. That might hurt RT tasks, but if someone really cares about real-time and deterministic behaviour, then running the machine on its thermal limits is simply stupid. In fact any sensible RT system will bring itself into a safe state way before the machine runs into that condition. Thanks, tglx -- 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/