Re: [PATCH 1/3] drm/i915: Stop putting GGTT VMA at the head of the list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 04, 2014 at 10:02:19AM +0000, Tvrtko Ursulin wrote:
> 
> On 12/04/2014 09:48 AM, Chris Wilson wrote:
> >On Wed, Dec 03, 2014 at 02:59:24PM +0000, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> >>
> >>Multiple GGTT VMAs per object will be introduced in the near future which will
> >>make it impossible to guarantee normal GGTT view is at the head of the list.
> >>
> >>Purpose of this patch is to break this assumption straight away so any
> >>potential hidden assumptions in the code base can be bisected to this
> >>simple patch.
> >
> >No, please don't. The rationale for putting ggtt first is because it
> >puts the one vma that every object is likely to use at the front, and
> >makes it also the first in the list for debugging.
> 
> This came from talking with Daniel, but I don't understand why every
> object is likely to have a GGTT mapping?

Because the userspace usage pattern is such that it is typical that
every object is accessed through the GTT at some point in its life.

It's actually becoming less so as we use alternative mmappings, but it
will remain so for quite some time yet.
 
> With multiple GGTT views it may happen that only single GGTT VMA
> exists in the list but it is not the one current code would expect.
> So the idea was to break that to flesh out any potential hidden
> assumptions in the code. (I did not find any by just looking
> though.)
> 
> What kind of debugging you have in mind, error capture? Or actually
> inspecting memory of a live kernel?

Error capture inspection of memory of a live kernel.
-Chris

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





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux