Is this patch applied to mainline kernel git repository? I checked out Linus's one but it seemed not.
Or I would like to know how to enable user level read so that I do not need syscall to get the counter value which took about 400ns overhead per call on my machine. Thanks. On Tue, Mar 23, 2010 at 11:25 AM, Stephane Eranian <eran...@google.com>wrote: > This patch fixes the remapped counter support such that it now works > on X86 processors. > > There were several issues: > > - needed a way to allow (permission) user level read (via RDPMC on > x86) > - there was no way of scaling the count correctly > - values returned by RDPMC and prev_count did not have the same > "sign" extensions > - did work with Intel X86 fixed counters > > This patch adds a new sysctl control: > /proc/sys/kernel/perf_event_paranoid_user_read > > It is set by default. You must clear it to allow direct user read. > I chose not to include this in perf_event_paranoid because the > priority there > did not make sense w.r.t to this particular control point. It would > have required > an ABI change, i.e, changing the meaning of the existing values. The > fact that > we may want to restrict user read is independent of trace points, or > system-wide > monitoring. > > The patch adds a new field to the perf_mmap_page buffer header > (delta_base). > It is necessary to correctly scale the count. This new value > represents the > counter value when the event was last scheduled in. It cannot be > substracted > by the kernel from the total count because of scaling. The correct > formula is: > > count = offset * time_enabled/time_running + (raw_count - > prev_count) > > We expose prev_count. The rest was already there. We also correct > prev_count > to allow the substraction to work. On X86 (and possibly others), the > user read > instruction (RDPMC) returns the N-bit count where N is the counter > width, the > upper bits are zeroed. But prev_count is always a 64-bit negative > number. > To avoid having to expose the raw counter width, the kernel now > adjusts the > prev_count value exposed in perf_mmap_page to have only N-bit worth > of data. > > User read support on X86 is implemented for AMD processors, Intel > X86 processors > except Pentium 4. I know it is also supported there, but I don't > have a machine > to test this on. A specific patch will be submitted later on. > > For other architectures, e.g., PPC, SPARC, assuming they do offer > the ability > to read counts directly from user space, all that is needed is a > couple of new > arch specific functions: > - hw_perf_event_counter_width(): actual counter width > - hw_perf_event_index(): register index to pass to the user > instruction > - hw_perf_update_user_read_perm(): toggle permission to read > from userspace > > Signed-off-by: Stephane Eranian <eran...@google.com> > -- Heechul
------------------------------------------------------------------------------
_______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
