On Tue, May 18, 2010 at 9:02 PM, heechul Yun <heechul....@gmail.com> wrote: > 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.
It's not in. It is on the backburner for now. There were issues related with maintaining the timing information in case of multiplexing. The only way to avoid this was by pinning the events. > 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 > -- Stephane Eranian | EMEA Software Engineering Google France | 38 avenue de l'Opéra | 75002 Paris Tel : +33 (0) 1 42 68 53 00 This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks ------------------------------------------------------------------------------ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
