[lkml]   [2009]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ofa-general] Re: [GIT PULL] please pull ummunotify

* Jason Gunthorpe <> wrote:

> On Wed, Sep 30, 2009 at 11:44:56AM +0200, Ingo Molnar wrote:
> > > > OK. It would be nice to tie into something more general, but I
> > > > think I agree -- perf counters are missing the filtering and the "no
> > > > lost events" that ummunotify does have. [...]
> >
> > Performance events filtering is being worked on and now with the
> > proper non-DoS limit you've added you can lose events too, dont you?
> > So it's all a question of how much buffering to add - and with perf
> > events too you can buffer arbitrary large amount of events.
> No, the ummunotify does not loose events, that is the fundamental
> difference between it and all tracing schemes.
> Every call to ibv_reg_mr is paired with a call to ummunotify to create
> a matching watcher. Both calls allocate some kernel memory, if one
> fails the entire operation fails and userspace can do whatever it does
> on memory allocation failure.

We already support signal notification for perf events, and we also
support two modi of perf ring-buffer overflow notification. Adding a
third one that sends a signal when events are lost would be in line with

This would allow you to have the OOM semantics of requesting a SIGBUS -
or user-space could do other things: like print a warning in the app or
ignore the event overflow.

Which are all interesting things to do. (If you do that you might want
to add that to 'perf top' or 'perf record' as well.)

> After that point the scheme is perfectly lossless.

Well if it can OOM it's not lossless, obviously. You just define "event
loss" to be equivalent to "Destruction of the universe." ;-)


 \ /
  Last update: 2009-10-12 20:23    [W:0.079 / U:87.836 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site