All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akash Goel <akash.goel@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
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 12:07:06 +0530	[thread overview]
Message-ID: <1435646226.20771.140.camel@akashgoe-desktop> (raw)
In-Reply-To: <20150629200537.GA26189@nuc-i3427.alporthouse.com>

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 ?

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 ? 
Is this something, which we can implement and add a new patch to the
series ? 

Best regards
Akash

> What's the timeframe for a fix/revert here? (i.e. did this get merged
> for 4.2 or was it 4.3?)
> -Chris


> 


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-06-30  6:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-29 17:28 [PATCH] Revert "drm/i915: Allocate context objects from stolen" ville.syrjala
2015-06-29 19:53 ` Chris Wilson
2015-06-29 20:05   ` Chris Wilson
2015-06-30  6:37     ` Akash Goel [this message]
2015-06-30  8:31       ` Chris Wilson
2015-06-30  9:58       ` [PATCH] drm/i915: Migrate stolen objects before hibernation Chris Wilson
2015-06-30 10:11         ` Chris Wilson
2015-06-30 10:31         ` Chris Wilson
2015-06-30 10:54         ` Daniel Vetter
2015-06-30 11:03           ` Chris Wilson
2015-06-30 11:22             ` Daniel Vetter
2015-06-30 11:32               ` Chris Wilson
2015-06-30 11:54                 ` Daniel Vetter
2015-06-30 12:37                   ` Chris Wilson
2015-06-30 11:16           ` Chris Wilson
2015-06-30 12:00             ` Daniel Vetter
2015-06-30 11:20           ` Chris Wilson
2015-06-30 12:03             ` Daniel Vetter
2015-06-30 11:25           ` Chris Wilson
2015-06-30 12:07             ` Daniel Vetter
2015-06-30 12:47               ` Chris Wilson
2015-07-01 12:47                 ` Daniel Vetter
2015-07-01 12:59                   ` Chris Wilson
2015-07-01 13:49                     ` Daniel Vetter
2015-06-30  8:31 ` [PATCH] Revert "drm/i915: Allocate context objects from stolen" Jani Nikula
2015-06-30  9:44   ` Chris Wilson
2015-06-30 10:07     ` Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1435646226.20771.140.camel@akashgoe-desktop \
    --to=akash.goel@intel.com \
    --cc=ankitprasad.r.sharma@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.