aboutsummaryrefslogtreecommitdiffstats
path: root/kernel/trace
diff options
context:
space:
mode:
authorSteven Rostedt <srostedt@redhat.com>2012-07-31 10:23:37 -0400
committerSteven Rostedt <rostedt@goodmis.org>2012-08-07 09:40:51 -0400
commit3c18c10bde65b6dcaffab7a4d040285e4defa49b (patch)
tree9b4545c063560d6986d03d7959793591d1eef118 /kernel/trace
parente52538965119319447c0800c534da73142c27be2 (diff)
tracing: Fix wakeup_rt self test on virtual machines
The warkeup_rt self test used msleep() calls to wait for real time tasks to wake up and run. On bare-metal hardware, this was enough as the scheduler should let the RT task run way before the non-RT task wakes up from the msleep(). If it did not, then that would mean the scheduler was broken. But when dealing with virtual machines, this is a different story. If the RT task wakes up on a VCPU, it's up to the host to decide when that task gets to schedule, which can be far behind the time that the non-RT task wakes up. In this case, the test would fail incorrectly. As we are not testing the scheduler, but instead the wake up tracing, we can use completions to wait and not depend on scheduler timings to see if events happen on time. Link: http://lkml.kernel.org/r/1343663105.3847.7.camel@fedora Reported-by: Fengguang Wu <fengguang.wu@intel.com> Tested-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Diffstat (limited to 'kernel/trace')
-rw-r--r--kernel/trace/trace_selftest.c27
1 files changed, 13 insertions, 14 deletions
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 1003a4d5eb25..2c00a691a540 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -1041,6 +1041,8 @@ static int trace_wakeup_test_thread(void *data)
1041 set_current_state(TASK_INTERRUPTIBLE); 1041 set_current_state(TASK_INTERRUPTIBLE);
1042 schedule(); 1042 schedule();
1043 1043
1044 complete(x);
1045
1044 /* we are awake, now wait to disappear */ 1046 /* we are awake, now wait to disappear */
1045 while (!kthread_should_stop()) { 1047 while (!kthread_should_stop()) {
1046 /* 1048 /*
@@ -1084,24 +1086,21 @@ trace_selftest_startup_wakeup(struct tracer *trace, struct trace_array *tr)
1084 /* reset the max latency */ 1086 /* reset the max latency */
1085 tracing_max_latency = 0; 1087 tracing_max_latency = 0;
1086 1088
1087 /* sleep to let the RT thread sleep too */ 1089 while (p->on_rq) {
1088 msleep(100); 1090 /*
1091 * Sleep to make sure the RT thread is asleep too.
1092 * On virtual machines we can't rely on timings,
1093 * but we want to make sure this test still works.
1094 */
1095 msleep(100);
1096 }
1089 1097
1090 /* 1098 init_completion(&isrt);
1091 * Yes this is slightly racy. It is possible that for some
1092 * strange reason that the RT thread we created, did not
1093 * call schedule for 100ms after doing the completion,
1094 * and we do a wakeup on a task that already is awake.
1095 * But that is extremely unlikely, and the worst thing that
1096 * happens in such a case, is that we disable tracing.
1097 * Honestly, if this race does happen something is horrible
1098 * wrong with the system.
1099 */
1100 1099
1101 wake_up_process(p); 1100 wake_up_process(p);
1102 1101
1103 /* give a little time to let the thread wake up */ 1102 /* Wait for the task to wake up */
1104 msleep(100); 1103 wait_for_completion(&isrt);
1105 1104
1106 /* stop the tracing. */ 1105 /* stop the tracing. */
1107 tracing_stop(); 1106 tracing_stop();