[Intel-gfx] [PATCH] [RFC] drm/i915: Restore LRU evict order, with a twist!

Daniel Vetter daniel at ffwll.ch
Sun May 16 19:16:56 CEST 2010


On Sat, May 15, 2010 at 06:17:12PM +0100, Chris Wilson wrote:
> This only leaves the question of whether it provides sufficient protection
> against the page-fault-of-doom.

I've thought a bit about this and I can easily come up with tons of
scenarios where fair-lru-eviction is better than protect-mmapped-objects.
Then only possible problem I see is when the gpu and the cpu are both
competing for gtt space (at the same time). With just fair-lru-eviction,
the gpu has an advantage because it's objects are pinned for the whole
time it uses them.

But given that fallbacks suck anyway, I don't think this is a problem. And
fixing it should be easy by introducing a active_mmap list with the
following rules:
- Insert objects at the tail when mmapping or faulting them.
- Move them from active_mmap list to the inactive list when unmmapping.
- In evict_something shrink the active_mmap list (from the head) to the
  same size of the active list. I.e. when we shrink the working set size
  of the gpu active set to n bytes, shrink the active_mmap list, too, such
  that it has about the same size (in bytes). Like with the linux mm
  active/inactive split, shoot down all ptes pointing to he objects just
  moved to the inactive list. This way the mistake of moving an active
  object to the inactive list can be immediatly corrected (on the next
  fault).

Essentially your protect-mmapped-objects patch with a twist that allows to
kick out objects userspace has mmapped without actually using (e.g.
batchbuffers of suspended clients).

-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list