Repository navigation
Conversation
This commit created a new pthread to fix the side-affect introduced by sched_setaffinity. Assisted-By: mimo-v2.6-pro Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
This commit updated the comments. Assisted-By: mimo-v2.6-pro Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
The spinlock test threads were created with SCHED_PRIORITY_MAX (255), which starves the watchdog feeding task (BSW_TASK_100MS, priority 191) on BMP systems with WdgM enabled. The WdgM satellite alive counter expires on secondary cores, triggering a WarmReset via SafetyErrMgr and powering off the system through semihosting exit. Add CONFIG_TESTING_OSTEST_SPINLOCK_PRIORITY Kconfig option (default 255) to allow platforms with watchdog monitoring to configure a lower priority. Use CONFIG_TESTING_OSTEST_SPINLOCK_PRIORITY in both spinlock_test() and run_test_thread() instead of hardcoded priority values. Assisted-By: mimo-v2.6-pro Signed-off-by: tengshuangshuang <tengshuangshuang@xiaomi.com>
…tion The LOOP_TIMES macro used CONFIG_TEST_LOOP_SCALE * 100000, but the Kconfig description states "N x 10,000". With the default scale of 100, this resulted in 10,000,000 iterations per lock type instead of the intended 1,000,000, causing ostest to exceed its 800-second timeout on QEMU targets with KASAN instrumentation enabled. Align the multiplier with the Kconfig description by changing 100000 to 10000. Assisted-By: mimo-v2.6-pro Co-authored-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com> Signed-off-by: vela-autotest03 <vela-autotest03@xiaomi.com>
The spinlock/rspinlock/seqcount performance test executes LOOP_TIMES = CONFIG_TEST_LOOP_SCALE * 100000 lock/unlock pairs per thread per lock type. With the default scale of 100 that is 10M operations per lock type, or 30M in total. When CONFIG_MM_KASAN is enabled every spin_lock_irqsave goes through kasan_check_report, which itself takes the global kasan spinlock (g_lock). On single-core QEMU/emulator builds (e.g. goldfish-miwear with CONFIG_SMP_NCPUS=1 + CONFIG_MM_KASAN_GENERIC=y) this serializes each op through one extra spin + atomic RMW. A live GDB snapshot on goldfish-miwear measured ~10K ops/sec, putting the full spinlock_test well past any sensible test-runner timeout and causing ostest to miss the "Exiting with status" pattern. Add a MM_KASAN-conditional default of 5 (= 500K ops, ~150s total for the three lock types on the same board) so instrumented builds finish in time, while non-KASAN builds keep the original 100 scale and retain meaningful throughput numbers. Users can still override via menuconfig/defconfig when needed. Root cause: KASAN per-op overhead made the default LOOP_TIMES infeasible on instrumented QEMU/emulator builds. Fix: add `default 5 if MM_KASAN` to CONFIG_TEST_LOOP_SCALE and document the rationale in ---help---. Assisted-By: mimo-v2.6-pro Co-authored-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com> Signed-off-by: vela-autotest04 <vela-autotest04@xiaomi.com>
Remove aligned_data(64) from stack-local union since spinlock_t/ rspinlock_t/seqcount_t are all <= 8 bytes (power-of-2), naturally fitting within a single cache line without explicit alignment. Warning: ctc W597: alignment of automatic object limited to 4 File: apps/testing/ostest/spinlock.c Line: 365 Assisted-By: mimo-v2.6-pro Signed-off-by: zhangyuan29 <zhangyuan29@xiaomi.com>
cederom
left a comment
There was a problem hiding this comment.
Thank you @Fix-Point :-)
casaroli
left a comment
There was a problem hiding this comment.
testing/ostest/spinlock.c:253: The test needs no priority option: the final counters are right at any priority, and run_test_thread() already reads the priority of the caller with sched_getparam() (line 245) and then overwrites it. ostest runs at SCHED_PRIORITY_DEFAULT, so threads at that priority stay below a watchdog task.
Fix: keep the priority that sched_getparam() returns (here and at line 440), and remove CONFIG_TESTING_OSTEST_SPINLOCK_PRIORITY.
testing/ostest/spinlock.c:226: getpid() gives the process ID, which is the main ostest thread, so sched_setaffinity() still pins the main thread, also when spinlock_test() runs the test in a new pthread. The affinity side effect stays.
Fix: use sched_setaffinity(0, ...), which changes the calling thread.
testing/ostest/Kconfig:162: The help says "scale * 100000", but LOOP_TIMES is now CONFIG_TEST_LOOP_SCALE * 10000 (and the prompt says N x 10,000).
Fix: write "scale * 10000".
testing/ostest/spinlock.c:343: rspinlock_t is the recursive spinlock, not a read-write spinlock. The comment at line 437 says "default - 1", but the code sets the Kconfig value.
Fix: correct both comments.
|
Commits 15513a3 ("fix spinlock test loop count to match Kconfig description") and deb5eff ("lower spinlock loop scale under MM_KASAN") are signed off by Fix: have the human author of each commit sign it off with their own name and address. |
Summary
This PR included:
MAX_THREAD_NUMand the loop count;CONFIG_TESTING_OSTEST_SPINLOCK_PRIORITY— spinlock test threads were created atSCHED_PRIORITY_MAX(255), which starves watchdog-feeding tasks on systems with watchdog monitoring (e.g. BMP + WdgM), eventually triggering a WarmReset; the new option (default 255) lets platforms lower the priority, and is used in bothspinlock_test()andrun_test_thread();TEST_LOOP_SCALEis documented as "N x 10,000" but the code used* 100000; aligned to* 10000;MM_KASAN— avoid excessively slow runs (and watchdog implications) on KASAN builds;Impact
testing/ostestbuilds as before.qemu-armv7a, see Testing).Testing
Host: x86-64 Linux,
arm-none-eabi-gcc + QEMU (qemu-system-arm).Config:
qemu-armv7a:smp(-smp 4)Result:
spinlock_testcompletes on 1/2/3/4 threads with correct final counters (N x 1000000) and 0 errors.Log: