Hi Gilles,
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?
-Carsten.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
