From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756921Ab2HGWDL (ORCPT ); Tue, 7 Aug 2012 18:03:11 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:12035 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753090Ab2HGWDG (ORCPT ); Tue, 7 Aug 2012 18:03:06 -0400 X-Authority-Analysis: v=2.0 cv=LIjkseq9 c=1 sm=0 a=s5Htg7xnQOKvHEu9STBOug==:17 a=OpT9cpI26MMA:10 a=Ciwy3NGCPMMA:10 a=WljEw9WqRFgA:10 a=5SG0PmZfjMsA:10 a=bbbx4UPp9XUA:10 a=meVymXHHAAAA:8 a=20KFwNOVAAAA:8 a=VwQbUJbxAAAA:8 a=QyXUC8HyAAAA:8 a=_klPS0fu4QH-n4FdAu0A:9 a=QEXdDO2ut3YA:10 a=jEp0ucaQiEUA:10 a=dGJ0OcVc7YAA:10 a=jeBq3FmKZ4MA:10 a=pRiKuOgoGWEpPTmsHH0A:9 a=s5Htg7xnQOKvHEu9STBOug==:117 X-Cloudmark-Score: 0 X-Originating-IP: 72.230.195.127 Message-Id: <20120807220303.380504263@goodmis.org> User-Agent: quilt/0.60-1 Date: Tue, 07 Aug 2012 18:01:07 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Andrew Morton , Fengguang Wu Subject: [PATCH 1/3] tracing: Fix wakeup_rt self test on virtual machines References: <20120807220106.459308722@goodmis.org> Content-Disposition: inline; filename=0001-tracing-Fix-wakeup_rt-self-test-on-virtual-machines.patch Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="00GvhwF7k39YY" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --00GvhwF7k39YY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable From: Steven Rostedt 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 Tested-by: Fengguang Wu Signed-off-by: Steven Rostedt --- kernel/trace/trace_selftest.c | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c index 1003a4d..2c00a69 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) set_current_state(TASK_INTERRUPTIBLE); schedule(); =20 + complete(x); + /* we are awake, now wait to disappear */ while (!kthread_should_stop()) { /* @@ -1084,24 +1086,21 @@ trace_selftest_startup_wakeup(struct tracer *trace,= struct trace_array *tr) /* reset the max latency */ tracing_max_latency =3D 0; =20 - /* sleep to let the RT thread sleep too */ - msleep(100); + while (p->on_rq) { + /* + * Sleep to make sure the RT thread is asleep too. + * On virtual machines we can't rely on timings, + * but we want to make sure this test still works. + */ + msleep(100); + } =20 - /* - * Yes this is slightly racy. It is possible that for some - * strange reason that the RT thread we created, did not - * call schedule for 100ms after doing the completion, - * and we do a wakeup on a task that already is awake. - * But that is extremely unlikely, and the worst thing that - * happens in such a case, is that we disable tracing. - * Honestly, if this race does happen something is horrible - * wrong with the system. - */ + init_completion(&isrt); =20 wake_up_process(p); =20 - /* give a little time to let the thread wake up */ - msleep(100); + /* Wait for the task to wake up */ + wait_for_completion(&isrt); =20 /* stop the tracing. */ tracing_stop(); --=20 1.7.10.4 --00GvhwF7k39YY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJQIZCXAAoJEIy3vGnGbaoAnAoP/jqJFuSdkFXbc3eU7UzmLczZ 7dBFrwWlOU3NPY4w5ZXLBCZhkdExHq05sYIiDNHFD+y1afI0pVk/Q4zHyn7o1Wsm CC00KcAaAA85pUJmkb2F0Gm7bhqAjnxcCUBJxLbpb4dmsh3QTiiHK1hxxGTuTpDF 93xpvpiq/RNaf9ZkD+Rmm94EMus7tKGVyHsnxorb1FOmVJ0CeSkn4bD3ihJzkV5K 2afhH2DPFJwmZ+wSTbLtyaN7MK/Z+hnLRiDMDYPe4iPoNlu2jM25bL/ltiuPvYOW pYcnQ75mW7rEQdYPKhuyYkYssLpQX/WstbIqR+FEnG9NAjdocSubo6pOsSU/NEQr rg9/9P6kmI3eNiuHZA1uufp8VewaFUPAu6y7dg/WTOYW9eZDLu+jNXtYmmUoQGyF w1EbwOTt4CAIh+ERJZtgwPYYdMvSz5bRYRJzHgaPNmEai+90jJFIdoaRPgkGV8mn uXqNVHzMvRwHmToN0SXC5dTxS03W7DD8/5WFpduduIbIiygsVqqg6+dXVmb+6uE/ dngebLUpuXYGAcFTStaoDalVsVHCPfeuaCfGONiY1aQ2plopb6DJqLByBKaecFW9 UTkmlECbsSef3qvrOUaQx0N9QWP8xLQSsyQqtCwVYebjZdxtFnE+Jd5UxoOHnGvk p/g/Tpctfi6k6moiPyFG =0eGR -----END PGP SIGNATURE----- --00GvhwF7k39YY--