> > > So.. What is the problem with fork? The semantics of what should > > happen seem natural enough to me, the PD doesn't get copied to the > > child, so the MR stays with the parent. COW events on the pinned > > region must be resolved so that the physical page stays with the > > process that has pinned it - the pin is logically released in the > > child because the MR doesn't exist because the PD doesn't exist. > > This is getting away from the problem that ummunotify is solving, but > handling a COW fault generated by the parent by doing the copy in the > child seems like a pretty major, tricky change to make. The child may > have forked 100 more times in the meantime, meaning we now have to > change 101 memory maps ... the cost of page faults goes through the roof > probably...
Ummm... Perhaps my first question was wrong. I'm not intent to NAK your patch. I merely want to know your patch detail... ok, I ask you again as another word. - I guess you have your MPI implementaion w/ ummunotify, right? - I guess you have test sevaral pattern, right? if so, can we see your test result? - I think you can explain your MPI advantage/disadvantage against current OpenMPI (or mpich et al). - I guess your patch dramatically improve MPI implementaion, but it's not free. it request some limitation to MPI application, right? - I imagine multi thread and fork. Is there another linmitaion? - In past discuttion, you said ummunotify user should not use multi threading. you also think user should not fork? _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
