Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode

[Cy Schubert]

Are you running powers?

Do you use c-states?

What happens if you boot in (instead of switch to) turbo mode?

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<***@cschubert.com> or <***@freebsd.org>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Lev Serebryakov
Sent: 04/09/2018 13:50
To: FreeBSD Current; freebsd-***@freebsd.org
Subject: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode

Hello FreeBSD,

I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It
is 1.6GHz CPU with Turbo up to 2.somethingGHz.

If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz
according to dev.cpu.0.freq, and simple "openssl" test confirms it.

If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz even
if powerd is running.

It looks like some bug in interaction between cpufreq and Turbo mode of
this CPU.

[Lev Serebryakov]

Hello Cy,

Post by Cy Schubert
Are you running powers?

powerd? yes. With "adaptive" strategy"

Post by Cy Schubert
Do you use c-states?

Oops. My fault. I've forgot to set cx_lowest to C3 on all cores.
BTW, these four settings in rc.conf(5)

performance_cx_lowest
performance_cpu_freq
economy_cx_lowest
economy_cpu_freq

do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5!

Post by Cy Schubert
What happens if you boot in (instead of switch to) turbo mode?

Sorry? I could only turn Turbo mode on/off in BIOS before boot.

BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but
gives only 1601 Mhz, not 2240MHz max:

TURBO ON:
dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75

TURBO OFF:
dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75

But I could live with that :-)

[Eric van Gyzen]

Post by Lev Serebryakov
BTW, these four settings in rc.conf(5)
performance_cx_lowest
performance_cpu_freq
economy_cx_lowest
economy_cpu_freq
do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5!

They are used by /etc/rc.d/power_profile, but not in a way that grep can
find.

Post by Lev Serebryakov
BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but
dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75
dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75

1601 is not the actual frequency. That is just how it is reported. It
is almost certainly running much higher than 1601.

Eric

[Cy Schubert]

In message <43d68d5a-d8b7-965d-52a6-***@vangyzen.net>, Eric
van Gyzen

Post by Eric van Gyzen

Post by Lev Serebryakov
BTW, these four settings in rc.conf(5)
performance_cx_lowest
performance_cpu_freq
economy_cx_lowest
economy_cpu_freq
do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5!

They are used by /etc/rc.d/power_profile, but not in a way that grep can
find.

Post by Lev Serebryakov
BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but
dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 12

80/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/
800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75

Post by Lev Serebryakov
dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 12

00/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/70
0 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75
1601 is not the actual frequency. That is just how it is reported. It
is almost certainly running much higher than 1601.

We don't know this until we can independently verify it. Do you mind
running some benchmarks with and without turbo mode?

[Lev Serebryakov]

Post by Cy Schubert

Post by Eric van Gyzen
1601 is not the actual frequency. That is just how it is reported. It
is almost certainly running much higher than 1601.

We don't know this until we can independently verify it. Do you mind
running some benchmarks with and without turbo mode?

What could be adequate benchmarks for this? Something likje "openssl
speed aes128-cbc" or I need more specific one?

[D. Ebdrup]

Post by Lev Serebryakov

Post by Cy Schubert

Post by Eric van Gyzen
1601 is not the actual frequency. That is just how it is reported. It
is almost certainly running much higher than 1601.

We don't know this until we can independently verify it. Do you mind
running some benchmarks with and without turbo mode?

What could be adequate benchmarks for this? Something likje "openssl
speed aes128-cbc" or I need more specific one?

A new port called sysutils/turbostat can report actual turboboost
values for Intel CPUs.

Other OS', including older versions of Linux and Windows, as well as
other opensource and closedsource software, also exhibits this
behaviour of showing 1601MHz for a CPU that is turbo-boosting higher
than normal operating frequency (without ACPI P-levels) which is this
case is 1600MHz.

Unfortunately, I didn't have much luck looking for documentation that
covers how this can be added to FreeBSD base (preferably exposed via a
sysctl), but I suspect it would involve both machine-dependent and
machine-independent parts since both AMD, as well as ARM and other
architectures use some form of equivalent functionality.

Post by Lev Serebryakov
// Lev Serebryakov
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Lev Serebryakov]

Post by D. Ebdrup

Post by Lev Serebryakov

Post by Cy Schubert

Post by Eric van Gyzen
1601 is not the actual frequency. That is just how it is reported. It
is almost certainly running much higher than 1601.

We don't know this until we can independently verify it. Do you mind
running some benchmarks with and without turbo mode?

What could be adequate benchmarks for this? Something likje "openssl
speed aes128-cbc" or I need more specific one?

A new port called sysutils/turbostat can report actual turboboost
values for Intel CPUs.

Oh, thank you!

Post by D. Ebdrup
Unfortunately, I didn't have much luck looking for documentation that
covers how this can be added to FreeBSD base (preferably exposed via a
sysctl), but I suspect it would involve both machine-dependent and
machine-independent parts since both AMD, as well as ARM and other
architectures use some form of equivalent functionality.

It should become part of cpufreq(8) for sure.

[Conrad Meyer]

Post by Lev Serebryakov

Post by D. Ebdrup
A new port called sysutils/turbostat can report actual turboboost
values for Intel CPUs.
Unfortunately, I didn't have much luck looking for documentation that
covers how this can be added to FreeBSD base (preferably exposed via a
sysctl), but I suspect it would involve both machine-dependent and
machine-independent parts since both AMD, as well as ARM and other
architectures use some form of equivalent functionality.

It should become part of cpufreq(8) for sure.

It doesn't make sense as part of cpufreq(8) for two reasons:

First and foremost, it is GPL2 software.

Secondly, it is extremely machine-dependent software. It is
x86-specific and has a lot of different code to handle each
microarchitecture from Nehalem through Skylake. It would be one thing
if this was a small table, but it is 5000 lines of code.

Best,
Conrad

[Lev Serebryakov]

Post by Conrad Meyer

Post by Lev Serebryakov

Post by D. Ebdrup
Unfortunately, I didn't have much luck looking for documentation that
covers how this can be added to FreeBSD base (preferably exposed via a
sysctl), but I suspect it would involve both machine-dependent and
machine-independent parts since both AMD, as well as ARM and other
architectures use some form of equivalent functionality.

It should become part of cpufreq(8) for sure.

First and foremost, it is GPL2 software.

I didn't mean, exactly this code should become part of cpufreq(8).
cpufreq(8) is framework for all frequency settings, CPU power
management, etc., for all our platforms and Turbo mode of modern CPUs is
not different from that. We use cpufreq(8) for all before-Turbo
frequency management, why should not we use it for new extended
frequency management?

Post by Conrad Meyer
Secondly, it is extremely machine-dependent software. It is
x86-specific and has a lot of different code to handle each
microarchitecture from Nehalem through Skylake. It would be one thing
if this was a small table, but it is 5000 lines of code.

cpufreq(8) contains a lot of machine-dependent software in platform
directories like sys/x86/cpufreq already.