From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Emde Subject: Re: cyclictest better values with system load than without (OMAP3530 target) Date: Fri, 29 Nov 2013 22:10:48 +0100 Message-ID: <529902D8.4090100@osadl.org> References: <5294681E.10406@gmail.com> <20131126101232.21636c8f@sluggy> <20131129125623.GB31099@linutronix.de> <5298AE4B.7070806@osadl.org> <5298C292.2030502@xenomai.org> <5298C7D0.2080300@xenomai.org> <5298D090.7090000@osadl.org> <5298EC50.2010802@xenomai.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sebastian Andrzej Siewior , Clark Williams , Stefan Roese , linux-rt-users@vger.kernel.org To: Gilles Chanteperdrix Return-path: Received: from toro.web-alm.net ([62.245.132.31]:34084 "EHLO toro.web-alm.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752634Ab3K2VUQ (ORCPT ); Fri, 29 Nov 2013 16:20:16 -0500 In-Reply-To: <5298EC50.2010802@xenomai.org> Sender: linux-rt-users-owner@vger.kernel.org List-ID: On 11/29/2013 08:34 PM, Gilles Chanteperdrix wrote: > On 11/29/2013 06:36 PM, Carsten Emde wrote: >>> On 11/29/2013 05:36 PM, Gilles Chanteperdrix wrote: >>>> On 11/29/2013 04:10 PM, Carsten Emde wrote: >>>>> BTW: Power saving and real-time do not necessarily exclude each other. >>>>> If a - still deterministic - but a little longer latency is acceptable, >>>>> some light sleep states and a somewhat lower clock frequency may be >>>>> allowed which still may result in considerable energy saving. If, >>>>> however, the fastest possible real-time response is required, C states >>>>> and P states must be disabled (or set to polling and maximum speed, >>>>> respectively) and the power bill must be payed. >>>> Well, I do not fully agree. To be sure that you can clock down the >>>> processor for executing a task which has sufficient time to meet its >>>> deadline, your system must be "time triggered", all the timer events >>>> must be known in advance. Because on a fully dynamic system, you may >>>> make that decision, but a new timer may be scheduled which causes the >>>> system to miss its deadline whereas it would not have missed it if it >>>> had run at full speed. >>> And a second problem is that you must know the task WCET, which on a >>> modern system: >>> - depends on the task frequency; >>> - depends on the IRQ load. >>> Again, only a time triggered system seems to make this possible. >> Hmm, I'm not sure whether I correctly got your point. >> Let me try an example: A 1-GHz CPU of a given systems runs at full speed >> with frequency governor set to performance and provides the required >> real-time capabilities. When a second system with the same capabilities >> was needed, the 1-GHz CPU unfortunately was out of stock, and the >> decision was made to buy the 2-GHz variant of the processor. To save >> energy, however, the clock frequency of the second system was set to 1 >> GHz using the cpufreq interface. Are you arguing that the 2-GHz >> processor that is throttled down to 1 GHz has a slower response time >> than the 1-GHz processor that always runs at full speed? > I probably misread what you were saying and thought you were talking > about dynamically changing the processor frequency when knowing that the > WCET of a task allows running it with a smaller frequency and still meet > its deadline. The thing implemented here for instance: > https://code.google.com/p/xenomaiote/ Ah, no, the whole thing was about static setting. I got your point wrong since I didn't know the proposal to dynamically change the clock frequency in relation to the WCET of a task. Sounds like a cool feature - but maybe a little to early to appear on our PREEMPT_RT wish list ... Thanks, -Carsten.