Re: Strange problem with PREEMPT_RT

[Punit Agrawal <punitagrawal@gmail.com>]

John Kacur <jkacur@redhat.com> writes:

> On Thu, 30 Sep 2021, John Ogness wrote:
>
>> 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?
>
> I see this option was dropped from the help, will add it back.
>
>> 
>> 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.
>
> The thing is, we are not just trying to measure an environment, we are 
> also simulating a realtime application. If your realtime environment 
> doesn't disable c-states, then your realtime application probably
> should.

I agree something (firmware, OS, application) should disable c-states -
cyclictest doing it during measurements hides the fact that the system
isn't configured correctly for applications requiring low latencies.

I do too lean towards "altering system behaviour is better left outside
the application" as different system have different knobs and need
different tweaking to achieve low latency.

> It's always a question of are we trying to measure a worse case scenario 
> or a best case scenario.
>
> If I remove this default we're going to get a slew of reports from people 
> using cyclictest wondering why they aren't getting good realtime 
> performance.

Perhaps, this is a change best done with a major version bump. Not that
it'll stop users queries completely but hopefully more people will pay
attention to the changelog.

[...]