On Friday, January 30, 2009 1:21 am Andrew Morton wrote: > On Fri, 30 Jan 2009 10:13:55 +0100 Thomas Hellstr__m <[email protected]> wrote: > > >> Sounds right to me. The offsets are just handles, not real file > > >> objects or backing store addresses. We use them to take advantage of > > >> all the inode address mapping helpers, since they track stuff for us. > > >> > > >> That said, unmap_mapping_range may not be the best way to do this; > > >> basically we need a way to invalidate a given processes' mapping of a > > >> GTT range (which in turn is backed by real RAM). If there's some > > >> other way we should be doing this I'm all ears. > > > > > > Well, we'd need to call in the big guns on this one - I've already > > > stirred Hugh ;) > > > > > > unmap_mapping_range() is basically a truncate thing - it shoots down > > > all mappings of a range of a *file*. Across all processes in the > > > machine which map that file. > > > > > > If that isn't what you want to do (and it sounds that way) then you'd > > > want to use something which is mm_struct (or vma) centric, rather than > > > file-centric. zap_page_range(), methinks. > > > > I guess I was the one starting to use this function, so some explanation: > > > > When the drm device is used to provide address space for buffers, > > user-space actually see it as a file with a distinct offset where > > buffers are laid out in a linear fashion, To access a certain buffer you > > need to lseek() to the correct offset and then read() write() or, the > > more common use, mmap / munmap. > > > > When looking through its implementation, unmap_mapping_range() seemed to > > do exactly the thing I wanted, namely to kill all user-space mappings of > > all vmas of all processes mapping a part of the device address space. > > That's different from what Jesse said. That _is_ a more appropriate > use of unmap_mapping_range(). Although all the futzing that function > does with truncate_count is now looking inappropriately-placed.
Yeah I misspoke, we do need to blow away *all* the mappings, not just the ones for a given process (since the backing GTT mapping is gone/moved). We could probably use zap_page_range, but might have to do a bit more work in the driver if we did. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
