On Thu, Dec 10, 2015 at 02:52:57PM +0000, Chris Wilson wrote: > On Thu, Dec 10, 2015 at 03:06:55PM +0100, Daniel Vetter wrote: > > On Wed, Dec 09, 2015 at 03:52:52PM +0000, Dave Gordon wrote: > > > In a few places, we fill a GEM object with data, or overwrite some > > > portion of its contents other than a single page. In such cases, we > > > should mark the object dirty so that its pages in the pagecache are > > > written to backing store (rather than discarded) if the object is > > > evicted due to memory pressure. > > > > > > The cases where only a single page is touched are dealt with in a > > > separate patch. > > > > > > This incorporates and supercedes Alex Dai's earlier patch > > > [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted > > > > > > Signed-off-by: Dave Gordon <david.s.gordon@xxxxxxxxx> > > > Cc: Alex Dai <yu.dai@xxxxxxxxx> > > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Hm, did you drop the begin_cpu_access dma-buf one here? See my other mail, > > I think that one was legit. > > I thought begin-access was the sync point around the per-page mmap(), > but reading the current code "in kernel users", of which it is just > drm/udl. How would we interact with a future dma-buf mmap()? We might end up with a bool userspace. Or we could check obj->pages and only set dirty if that's set. A bit evil, but should work even for mmap. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
