On Thu, 2020-04-16 at 10:12 +0800, Like Xu wrote:
On the Intel SNR processors such as "Intel Atom(R) C6562", the
turbo_freq for 4C turbo may be zero which causes a divide by zero
exception and blocks the boot process when arch_scale_freq_tick().
When one of the preset base_freq or turbo_freq is meaningless,
we may disable frequency invariance.
Fixes: 1567c3e3467c ("x86, sched: Add support for frequency invariance")
Signed-off-by: Like Xu <like.xu@xxxxxxxxxxxxxxx>
---
arch/x86/kernel/smpboot.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index fe3ab9632f3b..741367ce4d14 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1958,6 +1958,9 @@ static bool core_set_max_freq_ratio(u64 *base_freq, u64 *turbo_freq)
*base_freq = (*base_freq >> 8) & 0xFF; /* max P state */
*turbo_freq = (*turbo_freq >> 24) & 0xFF; /* 4C turbo */
+ if (*turbo_freq == 0 || *base_freq == 0)
+ return false;
+
return true;
}
Hello Like Xu,
thanks for reporting this and for the patch. My preferred solution for when
the 4 cores turbo freq is detected as zero would be to look for the 1 core turbo
frequency, as we're likely on a machine with less than 4 cores. Is that the
case on your Atom C6562? I couldn't find it on ark.intel.com.
As per why I'd like to go with 1 core turbo instead of bailing out of freq
invariance entirely, I've left a comment in the openSUSE bugzilla with some
details: https://bugzilla.opensuse.org/show_bug.cgi?id=1166664#c35
The relevant part is:
:: The fix in this case is to take the 1 core turbo as normalizing factor. The
:: other choice would be to use the base frequency (no turbo at all), but using
:: base freq for normalization means that the ratio becomes current_freq / base_freq
:: which is an over-estimation, which leads the frequency governor to think the
:: CPU is more loaded than it really is and raise the frequency a bit too
:: aggressively. This is tolerable in performance-oriented servers but
:: inappropriate on small machines with 2 cores."
Regarding base_freq being reported as zero, you're right, that can happen too
and we've seen it in hypervisors.
I've just sent fixes for these two problems here:
https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@xxxxxxx/
Thanks,
Giovanni Gherdovich