lkml.org 
[lkml]   [2011]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectperf_event self-monitoring overhead regression
Hello

I've been tracking a performance regression with self-monitoring and
perf_event.

For a simple start/stop/read test, the overhead has increased about 10%
from the 2.6.32 kernel to 3.1. (this has been measured on a variety
of x86_64 machines).

This is as measured with the POSIX clock_gettime(CLOCK_REALTIME,&time)
calls. Potentially the issue is with this and not with perf_events.
As you can imagine it is hard to measure the performance of the perf_event
interface since you can't invoke perf_event on it.

In any case, I was trying to bisect some of these performance issues.
There was another jump in overhead between 3.0 and 3.1, so I tried there.
I had a bisectable test case, but after a tedious day-long bisect run the
problem bisected down to

commit 2d86a3f04e345b03d5e429bfe14985ce26bff4dc
Merge: 3960ef3 5ddac6b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Jul 26 17:13:04 2011 -0700

Merge branch 'next/board' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/l

Which seems unlikely. My git skills really aren't enough to try to figure
out why an ARM board merge would affect the overhead of the perf_event
syscalls on x86_64.

Is there a better way for trying to track down performance regressions
like this?

Thanks,

Vince
vweaver1@eecs.utk.edu



\
 
 \ /
  Last update: 2011-11-30 06:23    [W:0.058 / U:2.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site