Message ID | 20230605-kselftest-cpufreq-options-v1-1-d4621e0c7cbe@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp3431488vqr; Tue, 6 Jun 2023 07:20:53 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6zNPC+yLpgH29qVPdqrIjUYNHbaKjhkjpgpsJBULMlVTQkc7R8TsTbu6iYDDpMTQfpEIka X-Received: by 2002:a05:622a:1049:b0:3f6:b823:f2af with SMTP id f9-20020a05622a104900b003f6b823f2afmr2689704qte.1.1686061253238; Tue, 06 Jun 2023 07:20:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686061253; cv=none; d=google.com; s=arc-20160816; b=N1yqKclAJQRcHH9ylXI+1LV54PwHU83+kkpsqB89CWCszmlRe4LYkAVcOP58dZ2Qo8 IGzduVrhSzfA39aDdWwmwEXQi7Hj8dpwKGXOcwwNwEHCFgc8o9fGOGrQwL2lK7IAfhII Ry15Jgjmmbv07Dt467PDRUGL+ep3oJHLgn64oQQuyGNPJejAGQoaAlx5SugK5REfIUKr CGesS1r4WdW3gfSvwFHo358XgD0APcmcBNDUO1MbvIIMNlHq+xnPdpVOsz18y8Uhk1fE fwPA/tRrAAMrWpb77pFVhRWwh4aR2n+wBzBCEkDw0ndYAEqpFV0rWK0+CscWd2147ent xpIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=Li6MJa/sXRxhb88kRUIbGYTjsztEQUyAfpl4aKL49nM=; b=vgYjOsWK0DhgpdsaG2/Ia+Zv3gCvrA/h3Ub9O/3g7/14WA5CQIR4saKk3fxjNBZqZi R7pFGPjvM7cALGqj3AUNJYveRPHYECk00/rgtIet2yWEYPhTLr/NY9KW1iuNtQUVnUf+ gpOI1WjMxGSaW4IRgayvRdnumzip03Zf37m3RGlfOdIBUcv690YkTTpvCN0j7qkAAgB5 qTivzGem//rgCxjy2b93a5VEqkbcDDsTzF4BPHkq2vTFD+zhO+BPIPy3Ly653C3cqpSa CxEfyVaZNG+0e5b59z/0I0WxARLuACY9BuauDu0miV5/zt9sX/O38cHIzvxp50P3ELA+ RD5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=U513mg2p; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j8-20020ac85c48000000b003f6b025c0c5si2888062qtj.497.2023.06.06.07.20.38; Tue, 06 Jun 2023 07:20:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=U513mg2p; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237591AbjFFOMY (ORCPT <rfc822;xxoosimple@gmail.com> + 99 others); Tue, 6 Jun 2023 10:12:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237115AbjFFOMQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 6 Jun 2023 10:12:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD2E1D3; Tue, 6 Jun 2023 07:12:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4999561DB8; Tue, 6 Jun 2023 14:12:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05CD5C433D2; Tue, 6 Jun 2023 14:12:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686060734; bh=nYj9AbUU59HCaqannbEYbVUupazB1udPANPd7R8v5fQ=; h=From:Date:Subject:To:Cc:From; b=U513mg2pt/PkVILvX0n/tTQXpeUHYZtOFnWFoFW0UwGt6DSqq+qp7w0DZytaZL7X3 7IIvxbwVDW/vIBcFzkyRO0EA+l+xCTer77JfX8KA289KyQm7D+ZXH7u8w3cFES7MTo UBerx5hAMQtTvyZk9QTFFlJoujvTd4oK7D/ECPsLRci25/Fq8gSxibITHNizCqcpnT bTc8cLvdXs05pbBlds+Jg8w540qG8R4J6yynxoWLL7HecSO2Jcgc07bUvu14u9KKtd ZQuOGdUvcSylgdhKaclPeiC73awgc/EBvPcoBjM9HiedsWaHaRhBKYo7zow6Nauxns Tav0rZFR1wVnw== From: Mark Brown <broonie@kernel.org> Date: Tue, 06 Jun 2023 15:11:49 +0100 Subject: [PATCH] selftests/cpufreq: Don't enable generic lock debugging options MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230605-kselftest-cpufreq-options-v1-1-d4621e0c7cbe@kernel.org> X-B4-Tracking: v=1; b=H4sIAKQ+f2QC/x2NywrDIBBFfyXMugNW0xT6K6ULo2MjKWpn7ANC/ j0my3PhnLuAEEcSuHULMH2jxJwanE8duMmmJ2H0jUErbdSgLjgLvUIlqejKJzC9MZfaJEEd/OD 7a6+NMdD80QrhyDa5aS/8Ms/7XJhC/B+X98e6bj8VZnOCAAAA To: "Rafael J. Wysocki" <rafael@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>, Shuah Khan <shuah@kernel.org> Cc: linux-pm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org> X-Mailer: b4 0.13-dev-bfdf5 X-Developer-Signature: v=1; a=openpgp-sha256; l=2394; i=broonie@kernel.org; h=from:subject:message-id; bh=nYj9AbUU59HCaqannbEYbVUupazB1udPANPd7R8v5fQ=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkfz670xVO01Ifmckeit23E9d7DWAFVjrMqaG6WWQv 8TuP8bCJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZH8+uwAKCRAk1otyXVSH0LdwB/ 9IqeAx8yIONur8WnWgUToSGK2QrJMUBBj6P+M47oCrhbFaOvAis3W6FvK6RoXLxtCy96o+eycqABqr lBlwSy9EAS7ePr+qZdI5kJVIwamhwvc5sfuFSHEvGfhLlwDZx5ztUYZ9mpL3TshKL0/Vgqq9Dh/1ty WleOs4db9hWDhQcIqTLFOFsPgf5AZNYEgfyizWATaDsyi3P3Jt+dwm95c7+quAYL7GW4WS2OA2oWY9 iKRsRYZcbWLL+2L9333+3tP6gQqb92bfaEenhRRWdYj1eZqke7t/lihOtj1hdi8/ty2YzF5k4wXENX wN5uw1FcMUmDEHzXqr6GkflmaPct+J X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767963365078634983?= X-GMAIL-MSGID: =?utf-8?q?1767963365078634983?= |
Series |
selftests/cpufreq: Don't enable generic lock debugging options
|
|
Commit Message
Mark Brown
June 6, 2023, 2:11 p.m. UTC
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,
Comments
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.
On 6/6/23 21:45, Viresh Kumar wrote: > 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. > Thank you both. Applied to linux-kselftest next for Linux 6.5-rc1 This gives us time to ensure the above mentioned races are no longer an issue. thanks, -- Shuah
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