Re: 5.15.28-rt35 #2 SMP PREEMPT_RT: Should scheduling latency be as large as 800 usec?

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

On 2022-03-25, Gautam Thaker <ghthaker@gmail.com> wrote:
> Even after I set  to "-g performance"  and set "-d 3.2GHz -u 3.2GHz"  I get:
>
> ..[same for all CPUS 0-30 as well]
> analyzing CPU 31:
>   driver: intel_cpufreq
>   CPUs which run at the same hardware frequency: 31
>   CPUs which need to have their frequency coordinated by software: 31
>   maximum transition latency: 20.0 us.
>   hardware limits: 1.20 GHz - 3.20 GHz
>   available cpufreq governors: conservative, ondemand, userspace,
> powersave, performance, schedutil
>   current policy: frequency should be within 3.20 GHz and 3.20 GHz.
>                   The governor "performance" may decide which speed to use
>                   within this range.
>   current CPU frequency is 1.20 GHz.
>
> The current CPU freq is at 1.2 GHz.   SHould "current CPU frequency"
> be at 3.2 GHz now all the time?

Yes, it should.

> And even at 1.2GHz, if that freq is steady, why should 'hwlatdetect'
> report the 800 usec latency?

Why do you think it is steady?

> It seems my issues are something other
> than  "cpufreq-set" policy I am using. (SMIs?)

Perhaps your BIOS is performing some scaling via SMIs.

It might be interesting to burn your CPUs and see if they ramp up. And
then perform your cyclictest and hwlatdetect tests while they burn.

An effective way to burn your CPUs is just send them into infinite
loops:

for c in $(seq $(nproc)); do ( while true; do echo -n; done & ); done

Be sure check cpufreq-info while this is running.

John Ogness