Messages in this thread | | | Date | Thu, 1 Dec 2011 10:11:05 -0800 | Subject | Re: perf_event self-monitoring overhead regression | From | stephane eranian <> |
| |
Vince,
I take it your test is all about self-monitoring, single event, single thread. Did you try breaking down the cost using TSC and rdtsc() to pinpoint where the regression is coming from in the 3 perf_event syscalls you're using?
On Thu, Dec 1, 2011 at 5:59 AM, Vince Weaver <vweaver1@eecs.utk.edu> wrote: > On Wed, 30 Nov 2011, Linus Torvalds wrote: > >> On Wed, Nov 30, 2011 at 3:54 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: >> >> So bisect works really well for clear bugs that are 100% repeatable >> and have a very clear "did it happen or not" signature, but I'd be >> very leery indeed of using it with some performance anomaly. > > In this case, the bisection case is pretty clean. I run 1000 of the tests > and check the median value, and the values are always 7280us for good and > 7440us for bad. > > The problem is when it starts bisecting into the merges it drops from a > post-3.0 kernel into a much earlier 3.0-rc kernel (due to the ARM merge > history) and suddenly then the test becomes meaningless as it starts > returning other values such as 6880us. This is because the problem I am > tracking has ben gradually getting worse over time, and so I guess by > going back to a 3.0-rc it gets earlier than some other change that made > performance worse, and thus it becomes impossible to know if a commit is > good or not. > >> That said, maybe you can get the timings to be unambiguous enough by >> using 'rdtsc' in user space, and try the bisect again. > > I'll try but I'm guessing your first thought that this might be > un-bisectabe is probably true. > > Thanks, > > Vince > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |