Re: Strange problem with PREEMPT_RT

[John Ogness <john.ogness@linutronix.de>]

On 2021-09-30, John Kacur <jkacur@redhat.com> wrote:
>>>> With hackbench, the system is sufficiently busy to avoid the going
>>>> into idle.
>>>
>>> Not just that. cyclictest's usage of /dev/cpu_dma_latency has the side
>>> effect that it may disable some of the PM stuff in the system.
>>> So your system appears good but then when cyclictest is gone, the
>>> numbers go up.
>>>
>>> Maybe we should drop that so we observe a system without altering its
>>> behaviour?
>> 
>> +1
>> 
>> Developers wanting to explicitly cause this behavior can use --latency=
>> to enable it. Having it on as a default is misleading.
>
> Where does this "--latency=" option apply to?

It is the value written to /dev/cpu_dma_latency, which AFAIK writes the
maximum acceptable latency (in microseconds). This translates to the
allowed C states. cyclictest currently writes 0, which should keep the
processor in C0. For example, setting it to 1-5, should allow C0 and C1.

Using --laptop will cause cyclictest to avoid touching
/dev/cpu_dma_latency. But nobody would know that unless they looked at
the code.

IMHO, systems should be configured for production use and cyclictest
should just _measure_ latencies at a specified priority level. But by
default cyclictest is adjusting global system behavior during
measurements, thus providing results that the system (as it is actually
configured) would not be able to provide.

I realize that nobody wants to touch defaults. But I'm not sure users
are aware how important the --laptop option is for realistic
measurements. In fact, the description of --laptop even encourages users
_not_ to use it. :-/

John Ogness