http://bugzilla.opensuse.org/show_bug.cgi?id=1206371 Bug ID: 1206371 Summary: Perf trace may display bogus timings Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: grasland@lal.in2p3.fr QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 863498 --> http://bugzilla.opensuse.org/attachment.cgi?id=863498&action=edit Reproducer You will find attached a simple C program that sleeps in a loop, meant to mimick the behavior of the slurmctld Slurm daemon on which I actually observed the bug. You can compile it and run it with "gcc -std=c99 sleeper.c && ./a.out". While it's running, monitor clock_nanosleep syscalls with "perf trace -e clock_nanosleep", and if you're like me, you will eventually observe bogus timings (though it may take a few seconds and/or multiple runs) : --- [ ... ] 7615.211 (100.191 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 7715.414 (100.213 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 7815.640 ( ): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) ... 7915.876 (18446744073709.516 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 7915.876 (100.095 ms): slurmctld/2280 ... [continued]: clock_nanosleep()) = 0 8016.012 (100.073 ms): slurmctld/2280 clock_nanosleep(which_clock: 0, flags: 0, rqtp: 0x7fff25018b60, rmtp: NULL) = 0 [ ... ] --- I cannot reproduce this on another system running Tumbleweed, perhaps it has been fixed on newer kernel/perf releases? Or perhaps this is somehow specific to this Leap system in another, unknown way. If I were to bet on a possible explanation, I would wager that perf trace may not correctly handle task CPU migrations, but this is just an educated guess and advice on rigorously debugging this further is very much welcome. -- You are receiving this mail because: You are the assignee for the bug.