On Mon, 2016-11-28 at 09:57 -0700, Jason Gunthorpe wrote: > On Sun, Nov 27, 2016 at 04:02:16PM +0200, Haggai Eran wrote: > > I think blocking mmu notifiers against something that is basically > > controlled by user-space can be problematic. This can block things > > like > > memory reclaim. If you have user-space access to the device's > > queues, > > user-space can block the mmu notifier forever. > Right, I mentioned that.. Sorry, I must have missed it. > > On PeerDirect, we have some kind of a middle-ground solution for > > pinning > > GPU memory. We create a non-ODP MR pointing to VRAM but rely on > > user-space and the GPU not to migrate it. If they do, the MR gets > > destroyed immediately. > That sounds horrible. How can that possibly work? What if the MR is > being used when the GPU decides to migrate? Naturally this doesn't support migration. The GPU is expected to pin these pages as long as the MR lives. The MR invalidation is done only as a last resort to keep system correctness. I think it is similar to how non-ODP MRs rely on user-space today to keep them correct. If you do something like madvise(MADV_DONTNEED) on a non-ODP MR's pages, you can still get yourself into a data corruption situation (HCA sees one page and the process sees another for the same virtual address). The pinning that we use only guarentees the HCA's page won't be reused. > I would not support that > upstream without a lot more explanation.. > > I know people don't like requiring new hardware, but in this case we > really do need ODP hardware to get all the semantics people want.. > > > > > Another thing I think is that while HMM is good for user-space > > applications, for kernel p2p use there is no need for that. Using > From what I understand we are not really talking about kernel p2p, > everything proposed so far is being mediated by a userspace VMA, so > I'd focus on making that work. Fair enough, although we will need both eventually, and I hope the infrastructure can be shared to some degree. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
