- Linux-kselftest-mirror - lists.linaro.org

[next] [arm64] [gpio] BUG: key has not been registered! DEBUG_LOCKS_WARN_ON:

by Naresh Kamboju

While running kselftest recently added gpio gpio-sim.sh test case the following warning was triggered on Linux next tag 20210330 tag running on arm64 juno and hikey devices. GOOD: next-20210326 BAD: next-20210330 This is still happening today on Linux next tag 20210407. # selftests: gpio: gpio-sim.sh # 1. chip_name and dev_name attributes # 1.1. Chip name is communicated to user [ 143.081193] BUG: key ffff000800eba398 has not been registered! [ 143.087326] ------------[ cut here ]------------ [ 143.091987] DEBUG_LOCKS_WARN_ON(1) [ 143.092005] WARNING: CPU: 1 PID: 1821 at /usr/src/kernel/kernel/locking/lockdep.c:4688 lockdep_init_map_type+0xf0/0x298 [ 143.106223] Modules linked in: gpio_sim rfkill tda998x cec drm_kms_helper drm crct10dif_ce fuse [last unloaded: gpio_mockup] [ 143.117495] CPU: 1 PID: 1821 Comm: mv Not tainted 5.12.0-rc5-next-20210330 #1 [ 143.124645] Hardware name: ARM Juno development board (r2) (DT) [ 143.130572] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 143.136589] pc : lockdep_init_map_type+0xf0/0x298 [ 143.141302] lr : lockdep_init_map_type+0xf0/0x298 [ 143.146014] sp : ffff800013fb3560 [ 143.149330] x29: ffff800013fb3560 x28: 00000000ffffee4b [ 143.154655] x27: 00000000000011b4 x26: 0000000000001000 [ 143.159979] x25: ffff000800eba380 x24: 0000000000000000 [ 143.165303] x23: 0000000000000000 x22: 0000000000000000 [ 143.170626] x21: ffff80001382b000 x20: ffff000800eba398 [ 143.175949] x19: ffff000827ac32a8 x18: ffffffffffffffff [ 143.181273] x17: 0000000000000000 x16: 0000000000000000 [ 143.186595] x15: ffff800012900a88 x14: ffff800093fb3167 [ 143.191918] x13: ffff800013fb3175 x12: 000000000000a0ec [ 143.197241] x11: 0000000005f5e0ff x10: ffff800013fb30c0 [ 143.202565] x9 : ffff800013fb3560 x8 : 4e5241575f534b43 [ 143.207888] x7 : ffff800012989ad8 x6 : ffff800013fb3180 [ 143.213211] x5 : 0000000000000001 x4 : 0000000000000001 [ 143.218534] x3 : ffff800012901000 x2 : 0000000000000000 [ 143.223856] x1 : b4b7acac5f71bc00 x0 : 0000000000000000 [ 143.229180] Call trace: [ 143.231625] lockdep_init_map_type+0xf0/0x298 [ 143.235989] __kernfs_create_file+0xa8/0x1d0 [ 143.240268] sysfs_add_file_mode_ns+0xa8/0x1f8 [ 143.244718] internal_create_group+0x118/0x420 [ 143.249169] sysfs_create_group+0x2c/0x38 [ 143.253185] gpio_sim_probe+0x358/0x3c0 [gpio_sim] [ 143.257995] platform_probe+0x6c/0xd8 [ 143.261663] really_probe+0x16c/0x508 [ 143.265332] driver_probe_device+0x104/0x178 [ 143.269610] __device_attach_driver+0xa4/0x130 [ 143.274062] bus_for_each_drv+0x78/0xd8 [ 143.277903] __device_attach+0xf0/0x178 [ 143.281745] device_initial_probe+0x24/0x30 [ 143.285935] bus_probe_device+0xa0/0xa8 [ 143.289776] device_add+0x424/0x810 [ 143.293270] platform_device_add+0x12c/0x2c0 [ 143.297545] platform_device_register_full+0x124/0x150 [ 143.302692] gpio_sim_config_commit_item+0x160/0x1e0 [gpio_sim] [ 143.308628] configfs_rename+0x1dc/0x220 [ 143.312557] vfs_rename+0x394/0x960 [ 143.316051] do_renameat2+0x408/0x4c0 [ 143.319718] __arm64_sys_renameat+0x5c/0x70 [ 143.323908] el0_svc_common+0x7c/0x158 [ 143.327665] do_el0_svc+0x38/0x90 [ 143.330985] el0_svc+0x20/0x30 [ 143.334045] el0_sync_handler+0x8c/0xb0 [ 143.337886] el0_sync+0x13c/0x140 [ 143.341204] irq event stamp: 5607 [ 143.344520] hardirqs last enabled at (5607): [<ffff800011462dd8>] _raw_spin_unlock_irq+0x48/0x90 [ 143.353410] hardirqs last disabled at (5606): [<ffff8000114586c4>] __schedule+0x364/0x950 [ 143.361605] softirqs last enabled at (5602): [<ffff800010010958>] __do_softirq+0x510/0x63c [ 143.369971] softirqs last disabled at (5577): [<ffff8000100a7474>] irq_exit+0x1b4/0x1c0 [ 143.377992] ---[ end trace bc3c86ef609281aa ]--- # 1.2. chip_name returns 'none' if the chip is still pending Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git describe: next-20210330 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/juno/lkft/linux-nex… https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20210407/te… Full test log link, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20210330/te… git log --oneline next-20210326..next-20210330 -- tools/testing/selftests/gpio/ 9d940ab72645 selftests: gpio: add test cases for gpio-sim 8a4cb2823240 selftests: gpio: add a helper for reading GPIO line names ab1dbed6f4e8 selftests: gpio: provide a helper for reading chip info -- Linaro LKFT https://lkft.linaro.org

4 years, 5 months

2
5
0 0

[PATCH v2] selftests/resctrl: Change a few printed messages

by Fenghua Yu

Change a few printed messages to report test progress more clearly. Add a missing "\n" at the end of one printed message. Suggested-by: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Fenghua Yu <fenghua.yu(a)intel.com> --- Change log: v2: - Add "Pass:" and "Fail:" sub-strings back (Shuah). This is a follow-up patch of recent resctrl selftest patches and can be applied cleanly to: git git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git branch next. tools/testing/selftests/resctrl/cache.c | 2 +- tools/testing/selftests/resctrl/mba_test.c | 6 +++--- tools/testing/selftests/resctrl/mbm_test.c | 2 +- tools/testing/selftests/resctrl/resctrlfs.c | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/resctrl/cache.c b/tools/testing/selftests/resctrl/cache.c index 362e3a418caa..68ff856d36f0 100644 --- a/tools/testing/selftests/resctrl/cache.c +++ b/tools/testing/selftests/resctrl/cache.c @@ -301,7 +301,7 @@ int show_cache_info(unsigned long sum_llc_val, int no_of_bits, ret = platform && abs((int)diff_percent) > max_diff_percent && (cmt ? (abs(avg_diff) > max_diff) : true); - ksft_print_msg("%s cache miss rate within %d%%\n", + ksft_print_msg("%s Check cache miss rate within %d%%\n", ret ? "Fail:" : "Pass:", max_diff_percent); ksft_print_msg("Percent diff=%d\n", abs((int)diff_percent)); diff --git a/tools/testing/selftests/resctrl/mba_test.c b/tools/testing/selftests/resctrl/mba_test.c index 26f12ad4c663..1a1bdb6180cf 100644 --- a/tools/testing/selftests/resctrl/mba_test.c +++ b/tools/testing/selftests/resctrl/mba_test.c @@ -80,7 +80,7 @@ static void show_mba_info(unsigned long *bw_imc, unsigned long *bw_resc) avg_diff = (float)labs(avg_bw_resc - avg_bw_imc) / avg_bw_imc; avg_diff_per = (int)(avg_diff * 100); - ksft_print_msg("%s MBA: diff within %d%% for schemata %u\n", + ksft_print_msg("%s Check MBA diff within %d%% for schemata %u\n", avg_diff_per > MAX_DIFF_PERCENT ? "Fail:" : "Pass:", MAX_DIFF_PERCENT, @@ -93,10 +93,10 @@ static void show_mba_info(unsigned long *bw_imc, unsigned long *bw_resc) failed = true; } - ksft_print_msg("%s schemata change using MBA\n", + ksft_print_msg("%s Check schemata change using MBA\n", failed ? "Fail:" : "Pass:"); if (failed) - ksft_print_msg("At least one test failed"); + ksft_print_msg("At least one test failed\n"); } static int check_results(void) diff --git a/tools/testing/selftests/resctrl/mbm_test.c b/tools/testing/selftests/resctrl/mbm_test.c index 02b1ed03f1e5..8392e5c55ed0 100644 --- a/tools/testing/selftests/resctrl/mbm_test.c +++ b/tools/testing/selftests/resctrl/mbm_test.c @@ -37,7 +37,7 @@ show_bw_info(unsigned long *bw_imc, unsigned long *bw_resc, int span) avg_diff_per = (int)(avg_diff * 100); ret = avg_diff_per > MAX_DIFF_PERCENT; - ksft_print_msg("%s MBM: diff within %d%%\n", + ksft_print_msg("%s Check MBM diff within %d%%\n", ret ? "Fail:" : "Pass:", MAX_DIFF_PERCENT); ksft_print_msg("avg_diff_per: %d%%\n", avg_diff_per); ksft_print_msg("Span (MB): %d\n", span); diff --git a/tools/testing/selftests/resctrl/resctrlfs.c b/tools/testing/selftests/resctrl/resctrlfs.c index ade5f2b8b843..5f5a166ade60 100644 --- a/tools/testing/selftests/resctrl/resctrlfs.c +++ b/tools/testing/selftests/resctrl/resctrlfs.c @@ -570,14 +570,14 @@ bool check_resctrlfs_support(void) fclose(inf); - ksft_print_msg("%s kernel supports resctrl filesystem\n", + ksft_print_msg("%s Check kernel supports resctrl filesystem\n", ret ? "Pass:" : "Fail:"); if (!ret) return ret; dp = opendir(RESCTRL_PATH); - ksft_print_msg("%s resctrl mountpoint \"%s\" exists\n", + ksft_print_msg("%s Check resctrl mountpoint \"%s\" exists\n", dp ? "Pass:" : "Fail:", RESCTRL_PATH); if (dp) closedir(dp); -- 2.31.1

4 years, 5 months

2
2
0 0

[PATCH] Documentation: kunit: add tips for using current->kunit_test

by Daniel Latypov

As of commit 359a376081d4 ("kunit: support failure from dynamic analysis tools"), we can use current->kunit_test to find the current kunit test. Mention this in tips.rst and give an example of how this can be used in conjunction with `test->priv` to pass around state and specifically implement something like mocking. There's a lot more we could go into on that topic, but given that example is already longer than every other "tip" on this page, we just point to the API docs and leave filling in the blanks as an exercise to the reader. Also give an example of kunit_fail_current_test(). Signed-off-by: Daniel Latypov <dlatypov(a)google.com> --- Documentation/dev-tools/kunit/tips.rst | 78 +++++++++++++++++++++++++- 1 file changed, 76 insertions(+), 2 deletions(-) diff --git a/Documentation/dev-tools/kunit/tips.rst b/Documentation/dev-tools/kunit/tips.rst index a6ca0af14098..8d8c238f7f79 100644 --- a/Documentation/dev-tools/kunit/tips.rst +++ b/Documentation/dev-tools/kunit/tips.rst @@ -78,8 +78,82 @@ Similarly to the above, it can be useful to add test-specific logic. void test_only_hook(void) { } #endif -TODO(dlatypov(a)google.com): add an example of using ``current->kunit_test`` in -such a hook when it's not only updated for ``CONFIG_KASAN=y``. +This test-only code can be made more useful by accessing the current kunit +test, see below. + +Accessing the current test +-------------------------- + +In some cases, you need to call test-only code from outside the test file, e.g. +like in the example above or if you're providing a fake implementation of an +ops struct. +There is a ``kunit_test`` field in ``task_struct``, so you can access it via +``current->kunit_test``. + +Here's a slightly in-depth example of how one could implement "mocking": + +.. code-block:: c + + #include <linux/sched.h> /* for current */ + + struct test_data { + int foo_result; + int want_foo_called_with; + }; + + static int fake_foo(int arg) + { + struct kunit *test = current->kunit_test; + struct test_data *test_data = test->priv; + + KUNIT_EXPECT_EQ(test, test_data->want_foo_called_with, arg); + return test_data->foo_result; + } + + static void example_simple_test(struct kunit *test) + { + /* Assume priv is allocated in the suite's .init */ + struct test_data *test_data = test->priv; + + test_data->foo_result = 42; + test_data->want_foo_called_with = 1; + + /* In a real test, we'd probably pass a pointer to fake_foo somewhere + * like an ops struct, etc. instead of calling it directly. */ + KUNIT_EXPECT_EQ(test, fake_foo(1), 42); + } + + +Note: here we're able to get away with using ``test->priv``, but if you wanted +something more flexible you could use a named ``kunit_resource``, see :doc:`api/test`. + +Failing the current test +------------------------ + +But sometimes, you might just want to fail the current test. In that case, we +have ``kunit_fail_current_test(fmt, args...)`` which is defined in ``<kunit/test-bug.h>`` and +doesn't require pulling in ``<kunit/test.h>``. + +E.g. say we had an option to enable some extra debug checks on some data structure: + +.. code-block:: c + + #include <kunit/test-bug.h> + + #ifdef CONFIG_EXTRA_DEBUG_CHECKS + static void validate_my_data(struct data *data) + { + if (is_valid(data)) + return; + + kunit_fail_current_test("data %p is invalid", data); + + /* Normal, non-KUnit, error reporting code here. */ + } + #else + static void my_debug_function(void) { } + #endif + Customizing error messages -------------------------- base-commit: 0a50438c84363bd37fe18fe432888ae9a074dcab -- 2.31.0.208.g409f899ff0-goog

4 years, 5 months

3
2
0 0

[PATCH bpf-next v2 0/3] add batched ops support for percpu

by Pedro Tammela

This patchset introduces batched operations for the per-cpu variant of the array map. It also introduces a standard way to define per-cpu values via the 'BPF_PERCPU_TYPE()' macro, which handles the alignment transparently. This was already implemented in the selftests and was merely refactored out to libbpf, with some simplifications for reuse. The tests were updated to reflect all the new changes. v1 -> v2: - Amended a more descriptive commit message Pedro Tammela (3): bpf: add batched ops support for percpu array libbpf: selftests: refactor 'BPF_PERCPU_TYPE()' and 'bpf_percpu()' macros bpf: selftests: update array map tests for per-cpu batched ops kernel/bpf/arraymap.c | 2 + tools/lib/bpf/bpf.h | 10 ++ tools/testing/selftests/bpf/bpf_util.h | 7 -- .../bpf/map_tests/array_map_batch_ops.c | 114 +++++++++++++----- .../bpf/map_tests/htab_map_batch_ops.c | 48 ++++---- .../selftests/bpf/prog_tests/map_init.c | 5 +- tools/testing/selftests/bpf/test_maps.c | 16 +-- 7 files changed, 133 insertions(+), 69 deletions(-) -- 2.25.1

4 years, 5 months

2
7
0 0

[PATCH] selftests/resctrl: Change a few printed messages

by Fenghua Yu

A few printed messages contain pass/fail strings which should be shown in test results. Remove the pass/fail strings in the messages to avoid confusion. Add "\n" at the end of one printed message. Suggested-by: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Fenghua Yu <fenghua.yu(a)intel.com> --- This is a follow-up patch of recent resctrl selftest patches and can be applied cleanly to: git git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git branch next. tools/testing/selftests/resctrl/cache.c | 3 +-- tools/testing/selftests/resctrl/mba_test.c | 9 +++------ tools/testing/selftests/resctrl/mbm_test.c | 3 +-- tools/testing/selftests/resctrl/resctrlfs.c | 7 ++----- 4 files changed, 7 insertions(+), 15 deletions(-) diff --git a/tools/testing/selftests/resctrl/cache.c b/tools/testing/selftests/resctrl/cache.c index 362e3a418caa..310bbc997c60 100644 --- a/tools/testing/selftests/resctrl/cache.c +++ b/tools/testing/selftests/resctrl/cache.c @@ -301,8 +301,7 @@ int show_cache_info(unsigned long sum_llc_val, int no_of_bits, ret = platform && abs((int)diff_percent) > max_diff_percent && (cmt ? (abs(avg_diff) > max_diff) : true); - ksft_print_msg("%s cache miss rate within %d%%\n", - ret ? "Fail:" : "Pass:", max_diff_percent); + ksft_print_msg("Check cache miss rate within %d%%\n", max_diff_percent); ksft_print_msg("Percent diff=%d\n", abs((int)diff_percent)); ksft_print_msg("Number of bits: %d\n", no_of_bits); diff --git a/tools/testing/selftests/resctrl/mba_test.c b/tools/testing/selftests/resctrl/mba_test.c index 26f12ad4c663..a909a745754f 100644 --- a/tools/testing/selftests/resctrl/mba_test.c +++ b/tools/testing/selftests/resctrl/mba_test.c @@ -80,9 +80,7 @@ static void show_mba_info(unsigned long *bw_imc, unsigned long *bw_resc) avg_diff = (float)labs(avg_bw_resc - avg_bw_imc) / avg_bw_imc; avg_diff_per = (int)(avg_diff * 100); - ksft_print_msg("%s MBA: diff within %d%% for schemata %u\n", - avg_diff_per > MAX_DIFF_PERCENT ? - "Fail:" : "Pass:", + ksft_print_msg("Check MBA diff within %d%% for schemata %u\n", MAX_DIFF_PERCENT, ALLOCATION_MAX - ALLOCATION_STEP * allocation); @@ -93,10 +91,9 @@ static void show_mba_info(unsigned long *bw_imc, unsigned long *bw_resc) failed = true; } - ksft_print_msg("%s schemata change using MBA\n", - failed ? "Fail:" : "Pass:"); + ksft_print_msg("Check schemata change using MBA\n"); if (failed) - ksft_print_msg("At least one test failed"); + ksft_print_msg("At least one test failed\n"); } static int check_results(void) diff --git a/tools/testing/selftests/resctrl/mbm_test.c b/tools/testing/selftests/resctrl/mbm_test.c index 02b1ed03f1e5..e2e7ee4ec630 100644 --- a/tools/testing/selftests/resctrl/mbm_test.c +++ b/tools/testing/selftests/resctrl/mbm_test.c @@ -37,8 +37,7 @@ show_bw_info(unsigned long *bw_imc, unsigned long *bw_resc, int span) avg_diff_per = (int)(avg_diff * 100); ret = avg_diff_per > MAX_DIFF_PERCENT; - ksft_print_msg("%s MBM: diff within %d%%\n", - ret ? "Fail:" : "Pass:", MAX_DIFF_PERCENT); + ksft_print_msg("Check MBM diff within %d%%\n", MAX_DIFF_PERCENT); ksft_print_msg("avg_diff_per: %d%%\n", avg_diff_per); ksft_print_msg("Span (MB): %d\n", span); ksft_print_msg("avg_bw_imc: %lu\n", avg_bw_imc); diff --git a/tools/testing/selftests/resctrl/resctrlfs.c b/tools/testing/selftests/resctrl/resctrlfs.c index ade5f2b8b843..91cb3c48a7da 100644 --- a/tools/testing/selftests/resctrl/resctrlfs.c +++ b/tools/testing/selftests/resctrl/resctrlfs.c @@ -570,15 +570,12 @@ bool check_resctrlfs_support(void) fclose(inf); - ksft_print_msg("%s kernel supports resctrl filesystem\n", - ret ? "Pass:" : "Fail:"); - + ksft_print_msg("Check kernel support for resctrl filesystem\n"); if (!ret) return ret; dp = opendir(RESCTRL_PATH); - ksft_print_msg("%s resctrl mountpoint \"%s\" exists\n", - dp ? "Pass:" : "Fail:", RESCTRL_PATH); + ksft_print_msg("Check resctrl mountpoint \"%s\"\n", RESCTRL_PATH); if (dp) closedir(dp); -- 2.31.1

4 years, 5 months

2
3
0 0

[PATCH] kunit: fix -Wunused-function warning for __kunit_fail_current_test

by Daniel Latypov

When CONFIG_KUNIT is not enabled, __kunit_fail_current_test() an empty static function. But GCC complains about unused static functions, *unless* they're static inline. So add inline to make GCC happy. Signed-off-by: Daniel Latypov <dlatypov(a)google.com> Fixes: 359a376081d4 ("kunit: support failure from dynamic analysis tools") --- include/kunit/test-bug.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/kunit/test-bug.h b/include/kunit/test-bug.h index ce6f6edc7801..5fc58081d511 100644 --- a/include/kunit/test-bug.h +++ b/include/kunit/test-bug.h @@ -19,8 +19,8 @@ extern __printf(3, 4) void __kunit_fail_current_test(const char *file, int line, #else -static __printf(3, 4) void __kunit_fail_current_test(const char *file, int line, - const char *fmt, ...) +static inline __printf(3, 4) void __kunit_fail_current_test(const char *file, int line, + const char *fmt, ...) { } base-commit: 359a376081d4fadfb073e3ddeb6bd6dc94d98341 -- 2.31.0.208.g409f899ff0-goog

4 years, 5 months

3
2
0 0

[PATCH v3 0/4] KVM: cpuid: fix KVM_GET_EMULATED_CPUID implementation

by Emanuele Giuseppe Esposito

This series aims to clarify the behavior of the KVM_GET_EMULATED_CPUID ioctl, and fix a corner case where -E2BIG is returned when the nent field of struct kvm_cpuid2 is matching the amount of emulated entries that kvm returns. Patch 1 proposes the nent field fix to cpuid.c, patch 2 updates the ioctl documentation accordingly and patches 3 and 4 extend the x86_64/get_cpuid_test.c selftest to check the intended behavior of KVM_GET_EMULATED_CPUID. Signed-off-by: Emanuele Giuseppe Esposito <eesposit(a)redhat.com> --- v3: - clearer commit message and problem explanation - pre-initialize the stack variable 'entry' in __do_cpuid_func_emulated so that the various eax/ebx/ecx are initialized if not set by func. Emanuele Giuseppe Esposito (4): KVM: x86: Fix a spurious -E2BIG in KVM_GET_EMULATED_CPUID Documentation: KVM: update KVM_GET_EMULATED_CPUID ioctl description selftests: add kvm_get_emulated_cpuid to processor.h selftests: KVM: extend get_cpuid_test to include KVM_GET_EMULATED_CPUID Documentation/virt/kvm/api.rst | 10 +-- arch/x86/kvm/cpuid.c | 33 ++++--- .../selftests/kvm/include/x86_64/processor.h | 1 + .../selftests/kvm/lib/x86_64/processor.c | 33 +++++++ .../selftests/kvm/x86_64/get_cpuid_test.c | 90 ++++++++++++++++++- 5 files changed, 142 insertions(+), 25 deletions(-) -- 2.30.2

4 years, 5 months

3
7
0 0

[PATCH bpf-next 0/3] add batched ops support for percpu array

by Pedro Tammela

This patchset introduces batched operations for the per-cpu variant of the array map. It also introduces a standard way to define per-cpu values via the 'BPF_PERCPU_TYPE()' macro, which handles the alignment transparently. This was already implemented in the selftests and was merely refactored out to libbpf, with some simplifications for reuse. The tests were updated to reflect all the new changes. Pedro Tammela (3): bpf: add batched ops support for percpu array libbpf: selftests: refactor 'BPF_PERCPU_TYPE()' and 'bpf_percpu()' macros bpf: selftests: update array map tests for per-cpu batched ops kernel/bpf/arraymap.c | 2 + tools/lib/bpf/bpf.h | 10 ++ tools/testing/selftests/bpf/bpf_util.h | 7 -- .../bpf/map_tests/array_map_batch_ops.c | 114 +++++++++++++----- .../bpf/map_tests/htab_map_batch_ops.c | 48 ++++---- .../selftests/bpf/prog_tests/map_init.c | 5 +- tools/testing/selftests/bpf/test_maps.c | 16 +-- 7 files changed, 133 insertions(+), 69 deletions(-) -- 2.25.1

4 years, 5 months

2
5
0 0

[RFC v2 0/2] CPU-Idle latency selftest framework

by Pratik Rajesh Sampat

Changelog RFC v1-->v2 The timer based test produces run to run variance on some intel based systems that sport a mechansim of "C-state pre-wake" which can pre-wake a CPU from an idle state when timers are armed. Hence invoking the timer tests is now parameterized for systems and architectures that don't support pre-wakeup logic and need granular timer measurements along with IPI results. This RFC does not yet support treating of CPU 0s idle states differently especially as reported on Intel systems. More understanding is needed on systems to determine if only CPU 0 is treated differently of if they are more CPUs that cannot have its idle state properties changed. RFC v1: https://lkml.org/lkml/2021/3/15/492 --- A kernel module + userspace driver to estimate the wakeup latency caused by going into stop states. The motivation behind this program is to find significant deviations behind advertised latency and residency values. The patchset measures latencies for two kinds of events. IPIs and Timers As this is a software-only mechanism, there will additional latencies of the kernel-firmware-hardware interactions. To account for that, the program also measures a baseline latency on a 100 percent loaded CPU and the latencies achieved must be in view relative to that. To achieve this, we introduce a kernel module and expose its control knobs through the debugfs interface that the selftests can engage with. The kernel module provides the following interfaces within /sys/kernel/debug/latency_test/ for, IPI test: ipi_cpu_dest = Destination CPU for the IPI ipi_cpu_src = Origin of the IPI ipi_latency_ns = Measured latency time in ns Timeout test: timeout_cpu_src = CPU on which the timer to be queued timeout_expected_ns = Timer duration timeout_diff_ns = Difference of actual duration vs expected timer Sample output on a POWER9 system is as follows: # --IPI Latency Test--- # Baseline Average IPI latency(ns): 3114 # Observed Average IPI latency(ns) - State0: 3265 # Observed Average IPI latency(ns) - State1: 3507 # Observed Average IPI latency(ns) - State2: 3739 # Observed Average IPI latency(ns) - State3: 3807 # Observed Average IPI latency(ns) - State4: 17070 # Observed Average IPI latency(ns) - State5: 1038174 # Observed Average IPI latency(ns) - State6: 1068784 # # --Timeout Latency Test-- # Baseline Average timeout diff(ns): 1420 # Observed Average timeout diff(ns) - State0: 1640 # Observed Average timeout diff(ns) - State1: 1764 # Observed Average timeout diff(ns) - State2: 1715 # Observed Average timeout diff(ns) - State3: 1845 # Observed Average timeout diff(ns) - State4: 16581 # Observed Average timeout diff(ns) - State5: 939977 # Observed Average timeout diff(ns) - State6: 1073024 Things to keep in mind: 1. This kernel module + bash driver does not guarantee idleness on a core when the IPI and the Timer is armed. It only invokes sleep and hopes that the core is idle once the IPI/Timer is invoked onto it. Hence this program must be run on a completely idle system for best results 2. Even on a completely idle system, there maybe book-keeping tasks or jitter tasks that can run on the core we want idle. This can create outliers in the latency measurement. Thankfully, these outliers should be large enough to easily weed them out. 3. A userspace only selftest variant was also sent out as RFC based on suggestions over the previous patchset to simply the kernel complexeity. However, a userspace only approach had more noise in the latency measurement due to userspace-kernel interactions which led to run to run variance and a lesser accurate test. Another downside of the nature of a userspace program is that it takes orders of magnitude longer to complete a full system test compared to the kernel framework. RFC patch: https://lkml.org/lkml/2020/9/2/356 4. For Intel Systems, the Timer based latencies don't exactly give out the measure of idle latencies. This is because of a hardware optimization mechanism that pre-arms a CPU when a timer is set to wakeup. That doesn't make this metric useless for Intel systems, it just means that is measuring IPI/Timer responding latency rather than idle wakeup latencies. (Source: https://lkml.org/lkml/2020/9/2/610) For solution to this problem, a hardware based latency analyzer is devised by Artem Bityutskiy from Intel. https://youtu.be/Opk92aQyvt0?t=8266 https://intel.github.io/wult/ Pratik Rajesh Sampat (2): cpuidle: Extract IPI based and timer based wakeup latency from idle states selftest/cpuidle: Add support for cpuidle latency measurement drivers/cpuidle/Makefile | 1 + drivers/cpuidle/test-cpuidle_latency.c | 157 ++++++++++ lib/Kconfig.debug | 10 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/cpuidle/Makefile | 6 + tools/testing/selftests/cpuidle/cpuidle.sh | 323 +++++++++++++++++++++ tools/testing/selftests/cpuidle/settings | 2 + 7 files changed, 500 insertions(+) create mode 100644 drivers/cpuidle/test-cpuidle_latency.c create mode 100644 tools/testing/selftests/cpuidle/Makefile create mode 100755 tools/testing/selftests/cpuidle/cpuidle.sh create mode 100644 tools/testing/selftests/cpuidle/settings -- 2.17.1

4 years, 5 months

3
4
0 0

[PATCH 0/4] KVM statistics data fd-based binary interface

by Jing Zhang

This patchset provides a file descriptor for every VM and VCPU to read KVM statistics data in binary format. It is meant to provide a lightweight, flexible, scalable and efficient lock-free solution for user space telemetry applications to pull the statistics data periodically for large scale systems. The pulling frequency could be as high as a few times per second. In this patchset, every statistics data are treated to have some attributes as below: * architecture dependent or common * VM statistics data or VCPU statistics data * type: cumulative, instantaneous, * unit: none for simple counter, nanosecond, microsecond, millisecond, second, Byte, KiByte, MiByte, GiByte. Clock Cycles Since no lock/synchronization is used, the consistency between all the statistics data is not guaranteed. That means not all statistics data are read out at the exact same time, since the statistics date are still being updated by KVM subsystems while they are read out. Jing Zhang (4): KVM: stats: Separate common stats from architecture specific ones KVM: stats: Add fd-based API to read binary stats data KVM: stats: Add documentation for statistics data binary interface KVM: selftests: Add selftest for KVM statistics data binary interface Documentation/virt/kvm/api.rst | 169 ++++++++ arch/arm64/include/asm/kvm_host.h | 9 +- arch/arm64/kvm/guest.c | 42 +- arch/mips/include/asm/kvm_host.h | 9 +- arch/mips/kvm/mips.c | 67 +++- arch/powerpc/include/asm/kvm_host.h | 9 +- arch/powerpc/kvm/book3s.c | 68 +++- arch/powerpc/kvm/book3s_hv.c | 12 +- arch/powerpc/kvm/book3s_pr.c | 2 +- arch/powerpc/kvm/book3s_pr_papr.c | 2 +- arch/powerpc/kvm/booke.c | 63 ++- arch/s390/include/asm/kvm_host.h | 9 +- arch/s390/kvm/kvm-s390.c | 133 ++++++- arch/x86/include/asm/kvm_host.h | 9 +- arch/x86/kvm/x86.c | 71 +++- include/linux/kvm_host.h | 132 ++++++- include/linux/kvm_types.h | 12 + include/uapi/linux/kvm.h | 48 +++ tools/testing/selftests/kvm/.gitignore | 1 + tools/testing/selftests/kvm/Makefile | 3 + .../testing/selftests/kvm/include/kvm_util.h | 3 + .../selftests/kvm/kvm_bin_form_stats.c | 370 ++++++++++++++++++ tools/testing/selftests/kvm/lib/kvm_util.c | 11 + virt/kvm/kvm_main.c | 237 ++++++++++- 24 files changed, 1401 insertions(+), 90 deletions(-) create mode 100644 tools/testing/selftests/kvm/kvm_bin_form_stats.c base-commit: f96be2deac9bca3ef5a2b0b66b71fcef8bad586d -- 2.31.0.208.g409f899ff0-goog

4 years, 5 months

2
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror