From: Matthias Kaehlcke <mka@chromium.org>
To: Leonard Crestez <leonard.crestez@nxp.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Chanwoo Choi" <cw00.choi@samsung.com>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"MyungJoo Ham" <myungjoo.ham@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Artur Świgoń" <a.swigon@partner.samsung.com>,
"Angus Ainslie" <angus@akkea.ca>,
"Brendan Higgins" <brendanhiggins@google.com>,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
linux-pm@vger.kernel.org, linux-imx@nxp.com
Subject: Re: [PATCH v4 1/4] PM / QoS: Initial kunit test
Date: Tue, 26 Nov 2019 12:04:14 -0800 [thread overview]
Message-ID: <20191126200414.GD228856@google.com> (raw)
In-Reply-To: <be196b656bb5fbf2c59a179e6453aa963b862109.1574781196.git.leonard.crestez@nxp.com>
On Tue, Nov 26, 2019 at 05:17:10PM +0200, Leonard Crestez wrote:
> The pm_qos family of APIs are used in relatively difficult to reproduce
> scenarios such as thermal throttling so they benefit from unit testing.
>
> Start by adding basic tests from the the freq_qos APIs. It includes
> tests for issues that were brought up on mailing lists:
>
> https://patchwork.kernel.org/patch/11252425/#23017005
> https://patchwork.kernel.org/patch/11253421/
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> drivers/base/Kconfig | 4 ++
> drivers/base/power/Makefile | 1 +
> drivers/base/power/qos-test.c | 117 ++++++++++++++++++++++++++++++++++
> 3 files changed, 122 insertions(+)
> create mode 100644 drivers/base/power/qos-test.c
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index e37d37684132..d4ae1c1adf69 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -155,10 +155,14 @@ config DEBUG_TEST_DRIVER_REMOVE
>
> This option is expected to find errors and may render your system
> unusable. You should say N here unless you are explicitly looking to
> test this functionality.
>
> +config PM_QOS_KUNIT_TEST
> + bool "KUnit Test for PM QoS features"
> + depends on KUNIT
> +
> config HMEM_REPORTING
> bool
> default n
> depends on NUMA
> help
> diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
> index ec5bb190b9d0..8fdd0073eeeb 100644
> --- a/drivers/base/power/Makefile
> +++ b/drivers/base/power/Makefile
> @@ -2,7 +2,8 @@
> obj-$(CONFIG_PM) += sysfs.o generic_ops.o common.o qos.o runtime.o wakeirq.o
> obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o wakeup_stats.o
> obj-$(CONFIG_PM_TRACE_RTC) += trace.o
> obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o domain_governor.o
> obj-$(CONFIG_HAVE_CLK) += clock_ops.o
> +obj-$(CONFIG_PM_QOS_KUNIT_TEST) += qos-test.o
>
> ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
> diff --git a/drivers/base/power/qos-test.c b/drivers/base/power/qos-test.c
> new file mode 100644
> index 000000000000..3115db08d56b
> --- /dev/null
> +++ b/drivers/base/power/qos-test.c
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP
> + */
> +#include <kunit/test.h>
> +#include <linux/pm_qos.h>
> +
> +/* Basic test for aggregating two "min" requests */
> +static void freq_qos_test_min(struct kunit *test)
> +{
> + struct freq_constraints qos;
> + struct freq_qos_request req1, req2;
> + int ret;
> +
> + freq_constraints_init(&qos);
> + memset(&req1, 0, sizeof(req1));
> + memset(&req2, 0, sizeof(req2));
> +
> + ret = freq_qos_add_request(&qos, &req1, FREQ_QOS_MIN, 1000);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + ret = freq_qos_add_request(&qos, &req2, FREQ_QOS_MIN, 2000);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> +
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MIN), 2000);
> +
> + ret = freq_qos_remove_request(&req2);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MIN), 1000);
> +
> + ret = freq_qos_remove_request(&req1);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MIN),
> + FREQ_QOS_MIN_DEFAULT_VALUE);
> +}
> +
> +/* Test that requests for MAX_DEFAULT_VALUE have no effect */
> +static void freq_qos_test_maxdef(struct kunit *test)
> +{
> + struct freq_constraints qos;
> + struct freq_qos_request req1, req2;
> + int ret;
> +
> + freq_constraints_init(&qos);
> + memset(&req1, 0, sizeof(req1));
> + memset(&req2, 0, sizeof(req2));
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MAX),
> + FREQ_QOS_MAX_DEFAULT_VALUE);
> +
> + ret = freq_qos_add_request(&qos, &req1, FREQ_QOS_MAX,
> + FREQ_QOS_MAX_DEFAULT_VALUE);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> + ret = freq_qos_add_request(&qos, &req2, FREQ_QOS_MAX,
> + FREQ_QOS_MAX_DEFAULT_VALUE);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> +
> + /* Add max 1000 */
> + ret = freq_qos_update_request(&req1, 1000);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MAX), 1000);
> +
> + /* Add max 2000, no impact */
> + ret = freq_qos_update_request(&req2, 2000);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MAX), 1000);
> +
> + /* Remove max 1000, new max 2000 */
> + ret = freq_qos_remove_request(&req1);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MAX), 2000);
nit: this last part isn't really related with MAX_DEFAULT_VALUE. It's a
worthwhile test, but not necessarily in this test case. It might make more sense
to set one of the constraints to FREQ_QOS_MAX_DEFAULT_VALUE again, and verify it
doesn't have an impact.
Just a comment, there's nothing really wrong with how it is.
> +}
> +
> +/*
> + * Test that a freq_qos_request can be added again after removal
> + *
> + * This issue was solved by commit 05ff1ba412fd ("PM: QoS: Invalidate frequency
> + * QoS requests after removal")
> + */
> +static void freq_qos_test_readd(struct kunit *test)
> +{
> + struct freq_constraints qos;
> + struct freq_qos_request req;
> + int ret;
> +
> + freq_constraints_init(&qos);
> + memset(&req, 0, sizeof(req));
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MIN),
> + FREQ_QOS_MIN_DEFAULT_VALUE);
nit: you could do this check once in a dedicated test and omit it
in other tests to de-clutter
> +
> + /* Add */
> + ret = freq_qos_add_request(&qos, &req, FREQ_QOS_MIN, 1000);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MIN), 1000);
similar here, this test validates re-adding, another dedicated test
could verify once that the aggregate value is correct after adding a single
request. Checking the return value still is sensible, just in case.
I guess it can be argued either way, checking the values every time is
extra-safe, omitting the checks reduces clutter and might help to make it
clearer what the test really intends to verify.
> +
> + /* Remove */
> + ret = freq_qos_remove_request(&req);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MIN),
> + FREQ_QOS_MIN_DEFAULT_VALUE);
ditto
> + /* Add again */
> + ret = freq_qos_add_request(&qos, &req, FREQ_QOS_MIN, 2000);
> + KUNIT_EXPECT_EQ(test, ret, 1);
> + KUNIT_EXPECT_EQ(test, freq_qos_read_value(&qos, FREQ_QOS_MIN), 2000);
Here the explicit check makes sense, since we verify re-adding.
Anyway, my comments are just about possible improvements, it's also fine
as is:
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
next prev parent reply other threads:[~2019-11-26 20:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 15:17 [PATCH v4 0/4] PM / QoS: Restore DEV_PM_QOS_MIN/MAX_FREQUENCY Leonard Crestez
2019-11-26 15:17 ` [PATCH v4 1/4] PM / QoS: Initial kunit test Leonard Crestez
2019-11-26 20:04 ` Matthias Kaehlcke [this message]
2019-11-27 23:40 ` Leonard Crestez
2019-12-02 16:49 ` Brendan Higgins
2019-11-26 15:17 ` [PATCH v4 2/4] PM / QoS: Redefine FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX Leonard Crestez
2019-11-26 15:17 ` [PATCH v4 3/4] PM / QoS: Reorder pm_qos/freq_qos/dev_pm_qos structs Leonard Crestez
2019-11-26 15:17 ` [PATCH v4 4/4] PM / QoS: Restore DEV_PM_QOS_MIN/MAX_FREQUENCY Leonard Crestez
2019-11-26 21:01 ` Matthias Kaehlcke
2019-11-29 5:55 ` Leonard Crestez
2019-11-29 11:34 ` [PATCH v4 0/4] " Rafael J. Wysocki
2019-11-29 14:20 ` Leonard Crestez
2019-12-02 1:24 ` Chanwoo Choi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191126200414.GD228856@google.com \
--to=mka@chromium.org \
--cc=a.swigon@partner.samsung.com \
--cc=angus@akkea.ca \
--cc=brendanhiggins@google.com \
--cc=cw00.choi@samsung.com \
--cc=kunit-dev@googlegroups.com \
--cc=kyungmin.park@samsung.com \
--cc=leonard.crestez@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.