Re: [ofa-general] Re: [GIT PULL] please pull ummunotify

From: Peter Zijlstra
Date: Thu Sep 17 2009 - 10:43:36 EST


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.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/