On Thu, 2015-12-10 at 18:00 +0000, Dave Gordon wrote: > On 10/12/15 14:15, Tvrtko Ursulin wrote: > > > > On 10/12/15 13:17, Ankitprasad Sharma wrote: > >> On Thu, 2015-12-10 at 09:43 +0000, Tvrtko Ursulin wrote: > >>> Hi, > >>> > >>> Two more comments below: > >>> > >>> On 09/12/15 12:46, ankitprasad.r.sharma@xxxxxxxxx wrote: > >>>> From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >>>> > >>>> Ville reminded us that stolen memory is not preserved across > >>>> hibernation, and a result of this was that context objects now being > >>>> allocated from stolen were being corrupted on S4 and promptly hanging > >>>> the GPU on resume. > >>>> > >>>> We want to utilise stolen for as much as possible (nothing else will > >>>> use > >>>> that wasted memory otherwise), so we need a strategy for handling > >>>> general objects allocated from stolen and hibernation. A simple > >>>> solution > >>>> is to do a CPU copy through the GTT of the stolen object into a fresh > >>>> shmemfs backing store and thenceforth treat it as a normal objects. > >>>> This > >>>> can be refined in future to either use a GPU copy to avoid the slow > >>>> uncached reads (though it's hibernation!) and recreate stolen objects > >>>> upon resume/first-use. For now, a simple approach should suffice for > >>>> testing the object migration. > >>> > >>> Mention of "testing" in the commit message and absence of a path to > >>> migrate the objects back to stolen memory on resume makes me think this > >>> is kind of half finished and note really ready for review / merge ? > >>> > >>> Because I don't see how it is useful to migrate it one way and never > >>> move back? > >> I think that this is not much of a problem, as the purpose here is to > >> keep the object intact, to avoid breaking anything. > >> So as far as objects are concerned they will be in shmem and can be used > >> without any issue, and the stolen memory will be free again for other > >> usage from the user. > > > > I am not sure that is a good state of things. > > > > One of the things it means is that when user wanted to create an object > > in stolen memory, after resume it will not be any more. So what is the > > point in failing stolen object creation when area is full in the first > > place? We could just return a normal object instead. > > > > Then the question of objects which are allocated in stolen by the > > driver. Are they being re-allocated on resume or will also be stuck in > > shmemfs from then onward? > > > > And finally, one corner case might be that shmemfs plus stolen is a > > larger sum which will be attempted to restored in shmemfs only on > > resume. Will that always work if everything is fully populated and what > > will happen if we run out of space? > > > > At minimum all this should be discussed and explicitly documented in the > > commit message. > > > > Would it be difficult to implement the reverse path? > > Please don't migrate random objects to stolen! It has all sorts of > limitations that make it unsuitable for some types of object (e.g. > contexts). > > Only objects that were originally placed in stolen should ever be > candidates for the reverse migration ... Yes, obviously. We will consider only those objects which were originally placed in stolen area. > > .Dave. > Thanks, Ankit _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
