Hello, Ok, I've redone the tests under tip from this morning (Paris time). Everything is in http://damien.wyart.free.fr/ksoftirqd_pb/ * Ingo Molnar <mingo@xxxxxxx> [2009-02-15 20:31]: > Yes, an abstime trace would be useful. The corresponding file is trace_tip_2009.02.16_ksoftirqd_pb_abstime.txt.gz and there is also a trace without abstime: trace_tip_2009.02.16_ksoftirqd_pb.txt.gz > > checking TSC synchronization [CPU#0 -> CPU#1]: passed. > > Switched to high resolution mode on CPU 1 > Lets double-check your scheduler clock first. Without being able to > trust the clock we cannot trust the task stats nor the trace output. > What does this check display: > http://people.redhat.com/mingo/time-warp-test/time-warp-test.c The file is time-warp-test_result.txt I've let it run for a few tens of minutes; the first number varies slightly sometimes. The second one stays at 0. > Does it find any TSC time warps? Seems not. > Also, could you send the output of: > http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh > Run it while you can see the ksoftirqd anomaly. In fact I see it all the time when the machine is idle. When something runs (spamd for example), the running time of ksoftirqd stops increasing, and it goes back to increasing like crazy when idle state comes back. The corresponding file is cfs-debug-info-2009.02.16-08.09.17.gz Hope this will be useful; do not hesitate to ask for further info. Now that I have tip, I guess it will be easier. -- Damien -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
