[Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Fri Jan 25 10:46:19 UTC 2019
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.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list