[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <adaljklifkt.fsf@cisco.com>
Date: Fri, 11 Sep 2009 09:58:10 -0700
From: Roland Dreier <rdreier@...co.com>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc: Brice Goglin <Brice.Goglin@...ia.fr>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
general@...ts.openfabrics.org, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org
Subject: Re: [ofa-general] Re: [GIT PULL] please pull ummunotify
> 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...
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists