Messages in this thread | | | Subject | Re: [ofa-general] Re: [GIT PULL] please pull ummunotify | From | Peter Zijlstra <> | Date | Thu, 17 Sep 2009 16:43:13 +0200 |
| |
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.
| |