Hi Oleg,
On 2/25/2025 5:27 PM, Oleg Nesterov wrote:
On 02/24, Oleg Nesterov wrote:
Just in case, did you use
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/hackbench/hackbench.c
?
Or did you use another version?
I am running hackbench using lkp-tests which downloads hackbench source
from same rt-tests with version 2.8.
https://github.com/intel/lkp-tests.git
https://www.kernel.org/pub/linux/utils/rt-tests/rt-tests-2.8.tar.gz
Exactly what parameters did you use?
Exact command with parameters is
/usr/bin/hackbench -g 16 -f 20 --threads --pipe -l 100000 -s 100
If possible, please reproduce the hang again. How many threads/processes
sleeping in pipe_read() or pipe_write() do you see? (you can look at
/proc/$pid/stack).
In the latest hang, I saw 37 threads sleeping out of which 20 were
sleeping in pipe_read() and 17 in pipe_write().
Main hackbench thread (which spawns the readers and writers) has the
following stack trace:
[<0>] futex_wait_queue+0x6e/0x90
[<0>] __futex_wait+0x143/0x1c0
[<0>] futex_wait+0x69/0x110
[<0>] do_futex+0x147/0x1d0
[<0>] __x64_sys_futex+0x7c/0x1e0
[<0>] x64_sys_call+0x207a/0x2140
[<0>] do_syscall_64+0x6f/0x110
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
The readers have the following pipe_read stack trace:
[<0>] pipe_read+0x338/0x460
[<0>] vfs_read+0x308/0x350
[<0>] ksys_read+0xcc/0xe0
[<0>] __x64_sys_read+0x1d/0x30
[<0>] x64_sys_call+0x1b89/0x2140
[<0>] do_syscall_64+0x6f/0x110
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
The writers have the following pipe_write stack trace:
[<0>] pipe_write+0x370/0x630
[<0>] vfs_write+0x378/0x420
[<0>] ksys_write+0xcc/0xe0
[<0>] __x64_sys_write+0x1d/0x30
[<0>] x64_sys_call+0x16b3/0x2140
[<0>] do_syscall_64+0x6f/0x110
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Please pick one sleeping writer, and do
$ strace -p pidof_that_write
this should wake this writer up. If a missed wakeup is the only problem,
hackbench should continue.
I tried waking one of the writer and the benchmark progressed and
completed successfully.
The more info you can provide the better ;)
Oleg.
--
Thanks and Regards,
Swapnil
