Hi, Sorry for late reply.
The current support for mmaped count is broken on perf_event x86. It simply does not work. I think it only works on PPC at this point. furthermore, the default security level disallows rdpmc at the user level. The kernel would have to be changed (CR4). given that you are interested in profiling, there is no point in trying to use mmapped counter. the kernel has a kernel-level buffer, so the cost of exporting samples is amortized over a large number of samples. On Sat, Aug 13, 2011 at 2:13 PM, Ryan Johnson <ryan.john...@cs.utoronto.ca> wrote: > On 12/08/2011 11:07 PM, Vince Weaver wrote: >> On Fri, 12 Aug 2011, Ryan Johnson wrote: >>> Are there plans to enable the kernel support that perf events seems to >>> assume already exists? >> the libpfm4 tests are likely based on the libpfm3/perfmon2 code. The >> perfmon2 kernel patches allowed rdpmc as far as I know. > Bitten by wheel-reinventing? /usr/include/linux/perf_event.h suggests > essentially identical code as The Right Way to use mmapped events (see > the comment inside perf_event_mmap_page). > >> If you want rdpmc in a perf_event kernel you're going to have to bug the >> perf_event developers on the linux-kernel list. At least one of them >> wasn't against the idea, but I'm sure it's a pretty low priority for them. > I'd be happy to hack on some code a bit... the perfctr patches are > pretty straightforward... but I'm not familiar with the kernel and can't > tell at all by looking at the perf_events code whether the perfctr way > of doing things makes sense even as a private hack. I'm almost tempted > to just write a small kernel module that enables rdpmc unilaterally for > a pid... > > You had mentioned it was on your todo list; if you could share your > high-level idea of what you would have done that would give me a huge > head start in putting a patch together. > >> Is what you're doing timing critical enough that having a read() syscall >> instead is just too much? > I'm interested in L2 and LLC misses, and syscalls have a tendency to > clobber caches. Even if the kernel-side misses caused by a syscall > aren't counted directly, userspace will suffer (and count) more misses > later because of it. > > Off-topic: I really can't figure out how linux devs decide which > features to reject... microstate accounting patches were utterly > dismissed due to their potential performance impact, even though they > have a huge impact on system observability, but taking HW counter zero > away from the watchdog is verboten because it creates better dumps when > the kernel dies an ugly death. > >> There are issues involved with rdpmc, such as >> what to do if the events you've selected are multiplexing, etc. > If they don't want people to use rdpmc (e.g. no architectural support, > unimplemented feature, multiplexing complications, or for security > reasons), they could at least be polite enough to set index=-1. Right > now the test case works, often calling read() several times... until the > kernel initializes the mmapped page and tricks it into attempting rdpmc. > > I hesitate to bring that up, tho, because they'd probably just > unilaterally set index=-1 and never look at it again... > > Ryan > > > ------------------------------------------------------------------------------ > FREE DOWNLOAD - uberSVN with Social Coding for Subversion. > Subversion made easy with a complete admin console. Easy > to use, easy to manage, easy to install, easy to extend. > Get a Free download of the new open ALM Subversion platform now. > http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > perfmon2-devel mailing list > perfmon2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel > ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
