[ofa-general] Re: [GIT PULL] please pull ummunotify
KOSAKI Motohiro
kosaki.motohiro at jp.fujitsu.com
Tue Sep 15 00:03:04 PDT 2009
>
> > 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?
More information about the general
mailing list