Re: [perfmon2] Weird sampling result on Xeon E5410 CPU

2010-10-15 Thread stephane eranian
Hi, On Tue, Oct 12, 2010 at 11:59 AM, wrote: > Hi all, > >  I'm working with a system with Xeon E5410 processors. The Linux kernel > version is 2.6.27, and libpfm/pfmon v3.6 (released on 2008-10-13). >  The pfmon command line I used was: > pfmon --smpl-outfile=x --with-header --smpl-module=c

Re: [perfmon2] strange results with libpfm4

2010-10-15 Thread stephane eranian
Victor, FYI, I posted the kernel patch to fix this today on LKML. See: http://lkml.org/lkml/2010/10/15/192 On Thu, Oct 14, 2010 at 9:17 PM, stephane eranian wrote: > Victor, > > On Thu, Oct 14, 2010 at 3:05 PM, Victor Jimenez wrote: >> Hello, >> >> I am interested in being able to sample the p

Re: [perfmon2] [PATCH] perf_events: fix transaction recovery in group_sched_in()

2010-10-15 Thread Peter Zijlstra
On Fri, 2010-10-15 at 19:34 +0200, Stephane Eranian wrote: > > > Yes, makes sense.. I'm a bit hesitant to slap a -stable tag on it due to > > its size,.. Ingo, Paulus? > > > I was worried about the size too but I could not figure out another > smaller way of doing this. An alternative would be to

Re: [perfmon2] [PATCH] perf_events: fix transaction recovery in group_sched_in()

2010-10-15 Thread Stephane Eranian
On Fri, Oct 15, 2010 at 7:29 PM, Peter Zijlstra wrote: > On Fri, 2010-10-15 at 16:54 +0200, Stephane Eranian wrote: >> The group_sched_in() function uses a transactional approach to schedule >> a group of events. In a group, either all events can be scheduled or >> none are. To schedule each event

Re: [perfmon2] [PATCH] perf_events: fix transaction recovery in group_sched_in()

2010-10-15 Thread Peter Zijlstra
On Fri, 2010-10-15 at 16:54 +0200, Stephane Eranian wrote: > The group_sched_in() function uses a transactional approach to schedule > a group of events. In a group, either all events can be scheduled or > none are. To schedule each event in, the function calls event_sched_in(). > In case of error,

[perfmon2] [PATCH] perf_events: fix transaction recovery in group_sched_in()

2010-10-15 Thread Stephane Eranian
The group_sched_in() function uses a transactional approach to schedule a group of events. In a group, either all events can be scheduled or none are. To schedule each event in, the function calls event_sched_in(). In case of error, event_sched_out() is called on each event in the group. The probl

Re: [perfmon2] [PATCH] perf_events: fix bogus AMD64 generic TLB events

2010-10-15 Thread Peter Zijlstra
On Fri, 2010-10-15 at 15:15 +0200, Stephane Eranian wrote: > PERF_COUNT_HW_CACHE_DTLB:READ:MISS had a bogus umask value of 0 which > counts nothing. Needed to be 0x7 (to count all possibilities). > > PERF_COUNT_HW_CACHE_ITLB:READ:MISS had a bogus umask value of 0 which > counts nothing. Needed to

Re: [perfmon2] [PATCH] perf_events: fix bogus context time tracking

2010-10-15 Thread Peter Zijlstra
On Fri, 2010-10-15 at 15:26 +0200, Stephane Eranian wrote: > You can only call update_context_time() when the context > is active, i.e., the thread it is attached to is still running. > > However, perf_event_read() can be called even when the context > is inactive, e.g., user read() the counters.

[perfmon2] [PATCH] perf_events: fix bogus context time tracking

2010-10-15 Thread Stephane Eranian
You can only call update_context_time() when the context is active, i.e., the thread it is attached to is still running. However, perf_event_read() can be called even when the context is inactive, e.g., user read() the counters. The call to update_context_time() must be conditioned on the status o

[perfmon2] [PATCH] perf_events: fix bogus AMD64 generic TLB events

2010-10-15 Thread Stephane Eranian
PERF_COUNT_HW_CACHE_DTLB:READ:MISS had a bogus umask value of 0 which counts nothing. Needed to be 0x7 (to count all possibilities). PERF_COUNT_HW_CACHE_ITLB:READ:MISS had a bogus umask value of 0 which counts nothing. Needed to be 0x3 (to count all possibilities). Signed-off-by: Stephane Eranian