Re: [PATCH] Revert "drm/i915: Allocate context objects from stolen"

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Akash Goel <akash.goel@intel.com>
Cc: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Revert "drm/i915: Allocate context objects from stolen"
Date: Tue, 30 Jun 2015 09:31:06 +0100	[thread overview]
Message-ID: <20150630083106.GK15506@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <1435646226.20771.140.camel@akashgoe-desktop>

On Tue, Jun 30, 2015 at 12:07:06PM +0530, Akash Goel wrote:
> On Mon, 2015-06-29 at 21:05 +0100, Chris Wilson wrote:
> > On Mon, Jun 29, 2015 at 08:53:12PM +0100, Chris Wilson wrote:
> > > On Mon, Jun 29, 2015 at 08:28:35PM +0300, ville.syrjala@linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Stolen gets trashed during hibernation, so storing contexts there
> > > > is not a very good idea. On my IVB machines this leads to a totally
> > > > dead GPU on resume. A reboot is required to resurrect it. So let's
> > > > not store contexts where they will get trampled.
> > > 
> > > We need to disable use of stolen entirely then. Fortunately ring buffers
> > > are idle (and so trashable), but all plans for actually using stolen are
> > > off the cards then (e.g. the create2 request to allocate from stolen).
> > > 
> > > I think it is fairer to say that stolen memory is not restored, and to
> > > do so for hibernation of non-volatile objects would require allocation
> > > of ordinary buffers. Ack on the patch in the short term, does a long
> > > term plan of migrating I915_MADV_WILLNEED stolen objects to normal
> > > memory on hibernation sound acceptable? (I don't like how it makes
> > > hibernation special in terms of shutdown/suspend, but meh)
> > 
> > I can get a patch to do the migration ready tomorrow, though it will
> > certainly be quite a few interesting patches.
> > 
> Hi Chris,
> 
> Thanks for keeping us in the loop. 
> As you are aware, that we started working on the patches for utilizing
> the Stolen area, based on the placement preference flag passed by the
> User (extended gem_create ioctl for it). We are trying to get them
> reviewed. Would this use case of hibernation thwart that efforts ?

Yes. Since if we are not careful we can effectively loose the user data
across hibernation. So long as we can allocate fresh storage for those
objects during hibernation (and we can use the madv flags to limit what
we need to copy) then creating stolen objects for general use is fine.
I'll leave the debate as to whether we want to migrate such objects back
to stolen on thaw/first-use for later. (Gut feeling hibernate + stolen
will be so rare that the justification for migrating back will be
small.)

> Are you planning to add the support for taking the back up of the
> objects allocated from Stolen memory area, by copying them to shmem at
> the time of hibernation. Should the objects be copied back to Stolen
> area on resume ? 

Yes. Maybe.

> Is this something, which we can implement and add a new patch to the
> series ? 

It's something I need now as an alternative to reverting
context-in-stolen.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx