[Intel-gfx] [PATCH 2/2 v2] drm/i915: mark GEM objects dirty after overwriting their contents

Daniel Vetter daniel at ffwll.ch
Fri Dec 11 09:09:37 PST 2015


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 at intel.com>
> > > Cc: Alex Dai <yu.dai at intel.com>
> > > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > 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


More information about the Intel-gfx mailing list