Re: [PATCH 0/9] [RFC] fair-lru eviction

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, May 19, 2010 at 09:51:33PM +0200, Thomas Hellström wrote:
> Daniel,
> TTM releases the spinlock protecting the drm_mm manager in between
> evictions to be able to wait (without holding locks) for bo idle.
> That means that the lru list may have changed between the first
> eviction and the next. In practice, drivers either don't allow
> simultaneous bo validation or should disallow it if thrashing is
> likely to occur, so the likelyhood of the lru list changing in
> between evictions should be small but it needs to be taken into
> account.

Well, in my opinion ttm locking optimize for the wrong case: Usually there
should be a little bit of room free to fully pipeline everything. And if
it there is no room free anymore, performance is gonna dip anyway, so we
might as well block. I think the linux vm with the split between
asynchronous background writeback and synchronous writeback in case of low
amounts of free memory could be used as inspiration.

Whatever, I think ttm could use this fair eviction stuff even with the
current locking scheme: Do all the accounting under the spinlock, i.e.
- scanning the lru
- building up the eviction list
- mark the memory blocks as free (with drm_mm_put_block)
- reserve the complete free hole (needs a new function in drm_mm, but
  range-restricted allocations are not yet implemented yet, anyway) with a
  temporary object.

Then do the effective eviction outside the spinlock. iirc ttm already uses
such shadow (dunno what they're really called) objects for buffer moves.

> Nevertheless, the drm_mm.c cleanup is
> Acked-by: Thomas Hellstrom <thellstrom@vmwgfx.com>

Does that include the drm_mm_node->private pointer removal? Jerome naked
that one (but I've objected). Just to clarify.

> I'll leave it to the Intel guys to comment on the fair eviction stuff.
> 
> /Thomas

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