[Intel-gfx] [PATCH v4 30/38] drm: Compute tight evictions for drm_mm_scan

[Chris Wilson]

On Wed, Dec 28, 2016 at 02:01:29PM +0100, Daniel Vetter wrote:
> On Thu, Dec 22, 2016 at 08:36:33AM +0000, Chris Wilson wrote:
> > Compute the minimal required hole during scan and only evict those nodes
> > that overlap. This enables us to reduce the number of nodes we need to
> > evict to the bare minimum.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> 
> Again, for next time around pls cc: driver maintainers too.

etnaviv wants a cyclic allocator, at least looks like it, so it doesn't
fit the api very well.  (I can't tell if it is a misunderstanding of
drm_mm, or a design choice to try and implement a different allocation
strategy - strange fits happen on wraparound, as we then see a bad
combination of the cyclic and drm_mm's last-hole strategy.)
It actually wants something like

if (size > mmu->domain->geometry.aperture_end - mmu->last_iova)
	mmu->last_iova = mmu->domain->geometry.aperture_start;

drm_mm_for_each_node_in_range_safe(node, nn, &mmu->mm, mmu->last_iova,
				   mmu->last_iova + size) {
	etnaviv_iommu_remove_mapping(mmu, m);
	m->mmu = NULL;

	mmu->need_flush = true;
}

node->start = mmu->last_iova;
node->size = size;
drm_mm_reserve_node(&mmu->mm, node);

mmu->last_iova += size;

Which would serve it's needs more concisely. The push to make
drm_mm_node scale to large random patterns in i915 adversely affects
such simple users - we could make a very concise drm_mm_cyclic.
Though that would still have the danger of being a single consumer
API.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre