On Thu, 2009-09-17 at 07:24 -0700, Roland Dreier wrote: > > Anton Blanchard suggested a while back that this might be integrated > > with perf-counters, since perf-counters already does mmap() tracking and > > also provides events through an mmap()'ed buffer. > > > > Has anybody looked into this? > > I didn't see the original suggestion. Certainly hooking in to existing > infrastructure for user/kernel communication would be good. > > The fit doesn't seem great to me, although I am rather naive about perf > counters. The problem that ummunotify is trying to solve is to let an > app say 'for these 1000 address ranges (that possibly only cover a small > part of my total address space), please let me know when the mappings > are invalidated for any reason'. > > So getting those events in the kernel is no problem -- we have the MMU > notifier hooks that tell us exactly what we need to know. The issue is > purely the way userspace registers interest in address ranges, and how > to kernel returns the events. > > For perf counters it seems that one would have to create a new counter > for each address range... is that correct? And also I don't know if > perf counter has an analog for the fast path optimization that > ummunotify provides via a mmap'ed generation counter (a quick way for > userspace to see 'nothing happened since last time you checked').
You're right in that perf-counter currently doesn't provide a way to specify these ranges, we simply track all mmap() traffic. The thing is that mmap() data is basically a side channel. For your usage you'd basically have to open a NOP counter and only observe the mmap data. We could look at ways of adding ranges.. We do have a means of detecting if new data is available, we keep a data head index. If that moves, you've got new stuff. _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
