[Intel-gfx] [PATCH v2 35/40] drm: Apply tight eviction scanning to color_adjust

[Chris Wilson]

On Fri, Dec 16, 2016 at 04:14:30PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-12-16 at 07:47 +0000, Chris Wilson wrote:
> > Using mm->color_adjust makes the eviction scanner much tricker since we
> > don't know the actual neighbours of the target hole until after it is
> > created (after scanning is complete). To work out whether we need to
> > evict the neighbours because they impact upon the hole, we have to then
> > check the hole afterwards - requiring an extra step in the user of the
> > eviction scanner when they apply color_adjust.
> > 
> > v2: Massage kerneldoc.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> It's not optimal as a separate function, but good for now.

Yes, it's nasty that it requires a separate step by the caller to catch
for residual overlap. The problem is that we do require the
mm.color_adjust to be performed to tell if the user thinks there will be
overlap - and that requires the final state of the hole and its
neighbours.

Alternatives I considered were just a color_expand parameter and always
evicting the neighbouring nodes (but that is not great for us as most of
our nodes have one colour). Or I considered searching the node list to
find the overlaps and flag them (presuming eviction happened as we
intended). They all seemed to be worse than just asking the user to
check after eviction if they are using color_adjust.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre