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: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
