selftests/cpufreq: Don't enable generic lock debugging options

Currently the the config fragment for cpufreq enables a lot of generic
lock debugging.  While these options are useful when testing cpufreq
they aren't actually required to run the tests and are therefore out of
scope for the cpufreq fragement, they are more of a thing that it's good
to enable while doing testing than an actual requirement for cpufreq
testing specifically.  Having these debugging options enabled,
especially the mutex and spinlock instrumentation, mean that any build
that includes the cpufreq fragment is both very much larger than a
standard defconfig (eg, I'm seeing 35% on x86_64) and also slower at
runtime.

This is causing real problems for CI systems.  In order to avoid
building large numbers of kernels they try to group kselftest fragments
together, frequently just grouping all the kselftest fragments into a
single block.  The increased size is an issue for memory constrained
systems and is also problematic for systems with fixed storage
allocations for kernel images (eg, typical u-boot systems) where it
frequently causes the kernel to overflow the storage space allocated for
kernels.  The reduced performance isn't too bad with real hardware but
can be disruptive on emulated platforms.

In order to avoid these issues remove these generic instrumentation
options from the cpufreq fragment, bringing the cpufreq fragment into
line with other fragments which generally set requirements for testing
rather than nice to haves.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 tools/testing/selftests/cpufreq/config | 8 --------
 1 file changed, 8 deletions(-)


---
base-commit: ac9a78681b921877518763ba0e89202254349d1b
change-id: 20230605-kselftest-cpufreq-options-2fd6d4742333

Best regards,

On 06-06-23, 15:11, Mark Brown wrote:
> Currently the the config fragment for cpufreq enables a lot of generic
> lock debugging.  While these options are useful when testing cpufreq
> they aren't actually required to run the tests and are therefore out of
> scope for the cpufreq fragement, they are more of a thing that it's good
> to enable while doing testing than an actual requirement for cpufreq
> testing specifically.  Having these debugging options enabled,
> especially the mutex and spinlock instrumentation, mean that any build
> that includes the cpufreq fragment is both very much larger than a
> standard defconfig (eg, I'm seeing 35% on x86_64) and also slower at
> runtime.
> 
> This is causing real problems for CI systems.  In order to avoid
> building large numbers of kernels they try to group kselftest fragments
> together, frequently just grouping all the kselftest fragments into a
> single block.  The increased size is an issue for memory constrained
> systems and is also problematic for systems with fixed storage
> allocations for kernel images (eg, typical u-boot systems) where it
> frequently causes the kernel to overflow the storage space allocated for
> kernels.  The reduced performance isn't too bad with real hardware but
> can be disruptive on emulated platforms.
> 
> In order to avoid these issues remove these generic instrumentation
> options from the cpufreq fragment, bringing the cpufreq fragment into
> line with other fragments which generally set requirements for testing
> rather than nice to haves.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  tools/testing/selftests/cpufreq/config | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/tools/testing/selftests/cpufreq/config b/tools/testing/selftests/cpufreq/config
> index 75e900793e8a..ce5068f5a6a2 100644
> --- a/tools/testing/selftests/cpufreq/config
> +++ b/tools/testing/selftests/cpufreq/config
> @@ -5,11 +5,3 @@ CONFIG_CPU_FREQ_GOV_USERSPACE=y
>  CONFIG_CPU_FREQ_GOV_ONDEMAND=y
>  CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
>  CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
> -CONFIG_DEBUG_RT_MUTEXES=y
> -CONFIG_DEBUG_PLIST=y
> -CONFIG_DEBUG_SPINLOCK=y
> -CONFIG_DEBUG_MUTEXES=y
> -CONFIG_DEBUG_LOCK_ALLOC=y
> -CONFIG_PROVE_LOCKING=y
> -CONFIG_LOCKDEP=y
> -CONFIG_DEBUG_ATOMIC_SLEEP=y

FWIW, I enabled these earlier as cpufreq core had a history of races
that are normally not caught without these enabled. But I think we
have come a long way from that and these can be removed now.