linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...)
@ 2020-10-09 10:57 Marek Behún
  2020-10-12  5:19 ` Andre Heider
  0 siblings, 1 reply; 3+ messages in thread
From: Marek Behún @ 2020-10-09 10:57 UTC (permalink / raw)
  To: arm
  Cc: Tomasz Maciej Nowak, Luka Perkov, Gregory CLEMENT, Andre Heider,
	soc, Vladimir Vid, Russell King, Gérald Kerma,
	Miquel Raynal, Konstantin Porotchkin, pali, linux-arm-kernel

Hello,

I have a request for testing some patches that fix cpufreq issues on
Armada 3720 (EspressoBIN, uDPU, Devel Board, maybe others?).

It concerns top 4 commits of branch a3720-cpufreq-issues of repository
https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/

(log at https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=a3720-cpufreq-issues)

We've discovered a bug in Armada 3720 cpufreq driver that causes
base CPU frequency to drop to 800 MHz on systems configured to 1 GHz.
More info here:
https://www.spinics.net/lists/arm-kernel/msg844752.html

The patchset above led us to discover another bug, in the SOC itself,
that causes the CPU to behave weirdly when frequency changes to 1 GHz.
A similar erratum is documented by Marvell but only for systems where
base frequency is 1.2 GHz.

We've discovered that to make cpufreq scaling stable on Armada 3720
on systems with base frequency 1 GHz, we also have to set voltage levels
for L1, L2 and L3 loads to 1108 mV. (We were led to this by patch we found here
https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/page/2/?tab=comments#comment-80012).

We would like you to build this sources and test the ondemand cpufreq
governor on systems with variable CPU load, for at least 1 day (more is better).
If you could also test the userspace governor and randomly change frequency,
it would be great.

Please let me know if and when you are willing to do this.

Thank you.

Marek & Pali

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU,  ...)
  2020-10-09 10:57 Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...) Marek Behún
@ 2020-10-12  5:19 ` Andre Heider
  2020-10-26 14:54   ` Pali Rohár
  0 siblings, 1 reply; 3+ messages in thread
From: Andre Heider @ 2020-10-12  5:19 UTC (permalink / raw)
  To: Marek Behún, arm
  Cc: Tomasz Maciej Nowak, Luka Perkov, Gregory CLEMENT, soc,
	Vladimir Vid, Russell King, Gérald Kerma, Miquel Raynal,
	Konstantin Porotchkin, pali, linux-arm-kernel

Hi Marek,

On 09/10/2020 12:57, Marek Behún wrote:
> I have a request for testing some patches that fix cpufreq issues on
> Armada 3720 (EspressoBIN, uDPU, Devel Board, maybe others?).
> 
> It concerns top 4 commits of branch a3720-cpufreq-issues of repository
> https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/
> 
> (log at https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=a3720-cpufreq-issues)
> 
> We've discovered a bug in Armada 3720 cpufreq driver that causes
> base CPU frequency to drop to 800 MHz on systems configured to 1 GHz.
> More info here:
> https://www.spinics.net/lists/arm-kernel/msg844752.html
> 
> The patchset above led us to discover another bug, in the SOC itself,
> that causes the CPU to behave weirdly when frequency changes to 1 GHz.
> A similar erratum is documented by Marvell but only for systems where
> base frequency is 1.2 GHz.
> 
> We've discovered that to make cpufreq scaling stable on Armada 3720
> on systems with base frequency 1 GHz, we also have to set voltage levels
> for L1, L2 and L3 loads to 1108 mV. (We were led to this by patch we found here
> https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/page/2/?tab=comments#comment-80012).
> 
> We would like you to build this sources and test the ondemand cpufreq
> governor on systems with variable CPU load, for at least 1 day (more is better).
> If you could also test the userspace governor and randomly change frequency,
> it would be great.
> 
> Please let me know if and when you are willing to do this.

Thanks for hunting this one down!

I've applied your 4 patches to v5.9 and gave it a quick spin.

I'm using schedutil, which had the very same issue. It never actually 
switched to 1000mhz. It claimed it did, but the `mhz` util as well as 
the 7z benchmark proved it never used anything >800mhz.

Before:
$ 7z b

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 

p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 
CPUs LE)

LE
CPU Freq:   793   793   794   793   794   792   793   794 


RAM size:     985 MB,  # CPU hardware threads:   2 

RAM usage:    441 MB,  # Benchmark threads:      2 


                        Compressing  |                  Decompressing 

Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating 

          KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS 


22:        711   149    464    692  |      17501   194    770   1494 

23:        708   155    465    722  |      17595   198    770   1523 

24:        682   158    464    734  |      17079   196    764   1499 

25:        663   160    473    757  |      15595   189    734   1388
----------------------------------  | ------------------------------
Avr:             156    466    726  |              194    760   1476
Tot:             175    613   1101


After:
$ 7z b

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 
CPUs LE)

LE
CPU Freq:   992   998   998   994   996   997   997   997

RAM size:     987 MB,  # CPU hardware threads:   2
RAM usage:    441 MB,  # Benchmark threads:      2

                        Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
          KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:        866   151    559    843  |      22334   198    962   1907
23:        872   152    584    889  |      21809   197    959   1888
24:        808   145    599    869  |      11413   110    915   1002
25:        716   137    596    819  |      21092   198    949   1877
----------------------------------  | ------------------------------
Avr:             146    585    855  |              176    946   1669
Tot:             161    765   1262


The measured frequency as well as the performance data finally looks 
good, so:

Tested-by: Andre Heider <a.heider@gmail.com>

Thanks,
Andre

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU,  ...)
  2020-10-12  5:19 ` Andre Heider
@ 2020-10-26 14:54   ` Pali Rohár
  0 siblings, 0 replies; 3+ messages in thread
From: Pali Rohár @ 2020-10-26 14:54 UTC (permalink / raw)
  To: Andre Heider
  Cc: Marek Behún, Tomasz Maciej Nowak, Luka Perkov,
	Gregory CLEMENT, soc, Vladimir Vid, Russell King, arm,
	Gérald Kerma, Miquel Raynal, Konstantin Porotchkin,
	linux-arm-kernel

On Monday 12 October 2020 07:19:48 Andre Heider wrote:
> Hi Marek,
> 
> On 09/10/2020 12:57, Marek Behún wrote:
> > I have a request for testing some patches that fix cpufreq issues on
> > Armada 3720 (EspressoBIN, uDPU, Devel Board, maybe others?).
> > 
> > It concerns top 4 commits of branch a3720-cpufreq-issues of repository
> > https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/
> > 
> > (log at https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=a3720-cpufreq-issues)
> > 
> > We've discovered a bug in Armada 3720 cpufreq driver that causes
> > base CPU frequency to drop to 800 MHz on systems configured to 1 GHz.
> > More info here:
> > https://www.spinics.net/lists/arm-kernel/msg844752.html
> > 
> > The patchset above led us to discover another bug, in the SOC itself,
> > that causes the CPU to behave weirdly when frequency changes to 1 GHz.
> > A similar erratum is documented by Marvell but only for systems where
> > base frequency is 1.2 GHz.
> > 
> > We've discovered that to make cpufreq scaling stable on Armada 3720
> > on systems with base frequency 1 GHz, we also have to set voltage levels
> > for L1, L2 and L3 loads to 1108 mV. (We were led to this by patch we found here
> > https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/page/2/?tab=comments#comment-80012).
> > 
> > We would like you to build this sources and test the ondemand cpufreq
> > governor on systems with variable CPU load, for at least 1 day (more is better).
> > If you could also test the userspace governor and randomly change frequency,
> > it would be great.
> > 
> > Please let me know if and when you are willing to do this.
> 
> Thanks for hunting this one down!
> 
> I've applied your 4 patches to v5.9 and gave it a quick spin.

Hello! I have there a new version of Armada 3720 CPU patches. They are
in branch "a3720-cpufreq-issues" at my git repository:

https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git

Full commit log is here:
https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=a3720-cpufreq-issues

The main difference from previous version of patches is that voltage
level for L2 and L3 loads is not increased, so power consumption for 200
and 250 MHz frequency should not be changed. Only for L1 load (500 MHz)
is increased to 1108 mV.

Could you test ondemand governor with these new patches?

> I'm using schedutil, which had the very same issue. It never actually
> switched to 1000mhz. It claimed it did, but the `mhz` util as well as the 7z
> benchmark proved it never used anything >800mhz.
> 
> Before:
> $ 7z b
> 
> 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
> 
> p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs
> LE)
> 
> LE
> CPU Freq:   793   793   794   793   794   792   793   794
> 
> 
> RAM size:     985 MB,  # CPU hardware threads:   2
> 
> RAM usage:    441 MB,  # Benchmark threads:      2
> 
> 
>                        Compressing  |                  Decompressing
> 
> Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
> 
>          KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS
> 
> 
> 22:        711   149    464    692  |      17501   194    770   1494
> 
> 23:        708   155    465    722  |      17595   198    770   1523
> 
> 24:        682   158    464    734  |      17079   196    764   1499
> 
> 25:        663   160    473    757  |      15595   189    734   1388
> ----------------------------------  | ------------------------------
> Avr:             156    466    726  |              194    760   1476
> Tot:             175    613   1101
> 
> 
> After:
> $ 7z b
> 
> 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
> p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs
> LE)
> 
> LE
> CPU Freq:   992   998   998   994   996   997   997   997
> 
> RAM size:     987 MB,  # CPU hardware threads:   2
> RAM usage:    441 MB,  # Benchmark threads:      2
> 
>                        Compressing  |                  Decompressing
> Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
>          KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS
> 
> 22:        866   151    559    843  |      22334   198    962   1907
> 23:        872   152    584    889  |      21809   197    959   1888
> 24:        808   145    599    869  |      11413   110    915   1002
> 25:        716   137    596    819  |      21092   198    949   1877
> ----------------------------------  | ------------------------------
> Avr:             146    585    855  |              176    946   1669
> Tot:             161    765   1262
> 
> 
> The measured frequency as well as the performance data finally looks good,
> so:
> 
> Tested-by: Andre Heider <a.heider@gmail.com>
> 
> Thanks,
> Andre

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-10-26 14:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-09 10:57 Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...) Marek Behún
2020-10-12  5:19 ` Andre Heider
2020-10-26 14:54   ` Pali Rohár

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).