[RFC] syscalls/perf_event_open02: Fix failures
diff mbox series

Message ID 20180424124957.15634-1-chrubis@suse.cz
State Accepted
Delegated to: Cyril Hrubis
Headers show
Series
  • [RFC] syscalls/perf_event_open02: Fix failures
Related show

Commit Message

Cyril Hrubis April 24, 2018, 12:49 p.m. UTC
The testcase was failing randomly, it could be reproduced easily when
the machine is under load. To reproduce the issue just run a few
dd if=/dev/zero of=/dev/null to saturate your CPUs.

It has been sugessted that the reason for the failure are rounding
errors caused by a frequent preemption. I haven't got a definitive
answer from kernel devs for this but it's true that changing the process
pritority to realtime SCHED_FIFO for the measurement does fix the issue.

So we either delete the test or apply this patch.

Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
---
 .../kernel/syscalls/perf_event_open/perf_event_open02.c     | 13 +++++++++++++
 1 file changed, 13 insertions(+)

Comments

Cyril Hrubis May 3, 2018, 8:49 a.m. UTC | #1
Hi!
> The testcase was failing randomly, it could be reproduced easily when
> the machine is under load. To reproduce the issue just run a few
> dd if=/dev/zero of=/dev/null to saturate your CPUs.
> 
> It has been sugessted that the reason for the failure are rounding
> errors caused by a frequent preemption. I haven't got a definitive
> answer from kernel devs for this but it's true that changing the process
> pritority to realtime SCHED_FIFO for the measurement does fix the issue.
> 
> So we either delete the test or apply this patch.

Any comments for this patch?

I would like to have this sorted out before the release...
Cyril Hrubis May 11, 2018, 11:48 a.m. UTC | #2
Hi!
> > The testcase was failing randomly, it could be reproduced easily when
> > the machine is under load. To reproduce the issue just run a few
> > dd if=/dev/zero of=/dev/null to saturate your CPUs.
> > 
> > It has been sugessted that the reason for the failure are rounding
> > errors caused by a frequent preemption. I haven't got a definitive
> > answer from kernel devs for this but it's true that changing the process
> > pritority to realtime SCHED_FIFO for the measurement does fix the issue.
> > 
> > So we either delete the test or apply this patch.
> 
> Any comments for this patch?
> 
> I would like to have this sorted out before the release...

Since nobody commented I will apply this next week, if you are againts
this patch, or want to ack it, speak up now :-).
Cyril Hrubis May 14, 2018, 10:09 a.m. UTC | #3
Hi!
Pushed.

Patch
diff mbox series

diff --git a/testcases/kernel/syscalls/perf_event_open/perf_event_open02.c b/testcases/kernel/syscalls/perf_event_open/perf_event_open02.c
index 13a17948a..0590ffb43 100644
--- a/testcases/kernel/syscalls/perf_event_open/perf_event_open02.c
+++ b/testcases/kernel/syscalls/perf_event_open/perf_event_open02.c
@@ -64,6 +64,7 @@  The -v flag makes it print out the values of each counter.
 #include <sys/prctl.h>
 #include <sys/types.h>
 #include <linux/types.h>
+#include <sched.h>
 
 #if HAVE_PERF_EVENT_ATTR
 # include <linux/perf_event.h>
@@ -286,6 +287,12 @@  static void verify(void)
 	unsigned long long vtsum = 0, vhsum = 0;
 	int i;
 	double ratio;
+	struct sched_param sparam = {.sched_priority = 1};
+
+	if (sched_setscheduler(0, SCHED_FIFO, &sparam)) {
+		tst_brkm(TBROK | TERRNO, cleanup,
+			 "sched_setscheduler(0, SCHED_FIFO, ...) failed");
+	}
 
 	if (prctl(PR_TASK_PERF_EVENTS_ENABLE) == -1) {
 		tst_brkm(TBROK | TERRNO, cleanup,
@@ -299,6 +306,12 @@  static void verify(void)
 			 "prctl(PR_TASK_PERF_EVENTS_DISABLE) failed");
 	}
 
+	sparam.sched_priority = 0;
+	if (sched_setscheduler(0, SCHED_OTHER, &sparam)) {
+		tst_brkm(TBROK | TERRNO, cleanup,
+			 "sched_setscheduler(0, SCHED_OTHER, ...) failed");
+	}
+
 	if (read(tsk0, &vt0, sizeof(vt0)) != sizeof(vt0)) {
 		tst_brkm(TBROK | TERRNO, cleanup,
 			 "error reading task clock counter");