[Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA

Chris Wilson chris at chris-wilson.co.uk
Fri Jan 25 13:38:09 UTC 2019


Quoting Tvrtko Ursulin (2019-01-25 10:46:19)
> 
> On 22/01/2019 14:19, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-18 16:03:27)
> >>
> >> On 18/01/2019 14:00, Chris Wilson wrote:
> >>> Our goal is to remove struct_mutex and replace it with fine grained
> >>> locking. One of the thorny issues is our eviction logic for reclaiming
> >>> space for an execbuffer (or GTT mmaping, among a few other examples).
> >>> While eviction itself is easy to move under a per-VM mutex, performing
> >>> the activity tracking is less agreeable. One solution is not to do any
> >>> MRU tracking and do a simple coarse evaluation during eviction of
> >>> active/inactive, with a loose temporal ordering of last
> >>> insertion/evaluation. That keeps all the locking constrained to when we
> >>> are manipulating the VM itself, neatly avoiding the tricky handling of
> >>> possible recursive locking during execbuf and elsewhere.
> >>>
> >>> Note that discarding the MRU is unlikely to impact upon our efficiency
> >>> to reclaim VM space (where we think a LRU model is best) as our
> >>> current strategy is to use random idle replacement first before doing
> >>> a search, and over time the use of softpinned 48b per-ppGTT is growing
> >>> (thereby eliminating any need to perform any eviction searches, in
> >>> theory at least).
> >>
> >> There is still no mention of list consolidation.
> > 
> > "Note that discarding the MRU (currently implemented as a pair of lists,
> > to avoid scanning the active list for a NONBLOCKING search)"
> > 
> > Is that enough to make it clear?
> 
> How about:
> 
> "Note that discarding the MRU, which is implemented both by not doing 
> list operations while tracking activity, and by replacing 
> active/inactive list with a single bound list, is unlikely..."
> 
> ?
> 
> Plus I really want a changelog and that stale comment which talks about 
> active/inactive *lists* updated.

But there's active/inactive lists within the list...
-Chris


More information about the Intel-gfx mailing list