On 2025/7/11 11:22, Steven Rostedt wrote:
On July 10, 2025 10:48:54 PM EDT, Tengda Wu wutengda@huaweicloud.com wrote:
The patch works well - after ~50 test iterations, we haven't observed any recurrence of the test case failures.
However, I'm concerned that using 'cat trace_pipe' (like the original 'cat trace' method) could bring back the stopping problem [1] on slower systems.
Could a slow trace_pipe reader (slower than sched event generation rate) reintroduce the original race condition?
Only if it doesn't find three different events, in which case the test would fail regardless.
The awk script exits out as soon as it finds 3: unique events. It won't go forever, even on slower machines.
-- Steve
Got it, thank you for explaining this. I have no further questions.
-- Tengda
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Some test details:
$ ./ftracetest -vvv subsystem-enable.tc [...]
- echo sched:*
- yield
- ping 127.0.0.1 -c 1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.538 ms
--- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 1ms rtt min/avg/max/mdev = 0.538/0.538/0.538/0.000 ms
- check_unique
- cat trace_pipe
- grep -v ^#
- awk BEGIN { cnt = 0; } { for (i = 0; i < cnt; i++) { if (event[i] == $5) { break; } } if (i == cnt) { event[cnt++] = $5; if (cnt > 2) { exit; } } } END { printf "%d", cnt; }
- count=3
- [ 3 -lt 3 ]
- do_reset
[...]
Regards, Tengda