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

Ingo Molnar
2009-10-13T06:38:16Z

* Brice Goglin <Brice.Goglin-MZpvjPyXg2s@public.gmane.org> wrote:

> Ingo Molnar wrote:
> > * Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> >
> >
> >> On Mon, Oct 12, 2009 at 08:19:44PM +0200, Ingo Molnar wrote:
> >>
> >>
> >>>> 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." ;-)
> >>>
> >> It can't OOM once the ummunotify registration is done - when an event
> >> occurs it doesn't allocate any memory and it doesn't loose events.
> >>
> >
> > Well, it has built-in event loss via the UMMUNOTIFY_FLAG_HINT mechanism:
> > any double events on the same range will cause an imprecise event to be
> > recorded and cause the loss of information.
> >
>
> The target (MPI) application doesn't care about how many events are
> coming here. It just needs to know whether something has been
> invalidated in the range. If so, it destroy the whole RDMA window
> anyway. So it's actually _good_ that multiple events are merged into a
> single one: the application only has to process a single event per
> partially-invalidated range.

it's not unconditionally good as the fuzzy-merge-events rule:

events[n].flags = UMMUNOTIFY_EVENT_FLAG_HINT;
events[n].hint_start = max(reg->start, reg->hint_start);
events[n].hint_end = min(reg->end, reg->hint_end);

in essence merges flushes into a single interval - which inevitably
might include areas of memory that were not flushed at all.

For example these two flushes:

[...] [...]

Would be merged into:

[..................]

Btw., isnt the above max/min logic buggy, causing lost events? Shouldnt
it be:

events[n].hint_start = min(reg->start, reg->hint_start);
events[n].hint_end = max(reg->end, reg->hint_end);

?

Ingo