[Intel-gfx] [PATCH] drm/i915: Migrate stolen objects before hibernation

[Chris Wilson]

On Tue, Jun 30, 2015 at 12:54:02PM +0200, Daniel Vetter wrote:
> > +	if (obj->ops->release)
> > +		obj->ops->release(obj);
> > +
> > +	obj->base.filp = file;
> > +	obj->ops = &i915_gem_object_ops;
> > +
> > +	obj->base.read_domains = I915_GEM_DOMAIN_CPU;
> > +	obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> 
> maybe wrap up in a shmem_reinit function and reuse in the gem object creation
> path for a bit more clarity (and to reduce chances we forget about this).

A bit dubious about this. I like the explicit domain handling as it
clearly matches the status of obj->file. The only thing that is then
shared with the normal creation is obj->ops, which is actually set in
i915_gem_object_init(). It's not clear that we actually have semantic
reuse with gem object creation.

> Wrt igt not sure whether we can do this in general, since it requires a
> working swap partition and working initrd support for hibernate. And
> hibernate is kinda a disregarded feature anyway, so imo meh. We could do
> an igt_system_hibernate_autowake() if we do the test though.

I was thinking of just a flush-stolen-to-shmemfs debugfs interface. With
create2 we will be able to create the stolen objects and can use the
existing debugfs files to verify placement.
 
> Imo trying to migrate backwards would be serious pain since we'd need to
> make sure no shm mmap is around and audit all the other places. Too much
> trouble for no gain (userspace can just realloc if needed).

Otoh, that would be a userspace error since part of the stolen ABI is
that CPU mmaps are verboten. The simplest way to do this would be keep
the obj->base.filp private (so not to change the ABI of initially stolen
objects) and then fix the existing i915_gem_object_get_pages_stolen()
function (which is currently a BUG()) to do the stolen recreation.
However, that introduces the possibilty of an error being returned to
userspace, so at that point to hide the failure we probably do want to a
full shmemfs conversion.

Hmm, honestly that seems quite tractable and self-contained.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre