[PATCH 3/5] drm/ttm: Use only DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN

[Thomas Hellstrom]

On 10/28/2014 12:10 PM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 06:35:04PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daenzer at amd.com>
>>
>> DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
>> against the idea of TTM_PL_FLAG_TOPDOWN:
>>
>> * The smallest hole may be in the overall bottom of the area
>> * If the hole isn't much larger than the BO, it doesn't make much
>>   difference whether the BO is placed at the bottom or at the top of the
>>   hole
>>
>> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
> tbh I think SEARCH_BEST is pretty much always a bad idea - it rips apart
> allocations from the same execbuf, and usually those get recycled around
> the same time. Which means you'll just fragment your mm even more if you
> try to find the best hole instead of just picking one and the stuffing the
> entire execbuf into it. So imo we might as well just kill it.
>
> Another one that I've advertised a bunch of times already is the scan
> roaster in drm_mm.c: Currently ttm just evicts until there's a big enough
> hole, which is fairly awful if you have quasi-segmented memory like with
> top-down/bottom-up schemes and different ranges for different units. With
> the roaster you just walk the lru and build up potential holes until
> there's a suitable one, and then only evict those buffers. Which means if
> you have a certain range of memory under very high pressure (e.g. the 256M
> which uvd can use or whatever it is), then you wont thrash all the other
> vram too.
>
> Cheers, Daniel
>
And I think I've commented each time why that is currently not possible
or at least worthile with TTM ;).

Although the idea is great, even if you make a nice list of suitable
buffers to evict, as soon as you drop the LRU spinlock, that list is
invalid. Worse, while you start evicting your list, other processes may
steal part of the hole you've created.

As some point we should perhaps figure out how to protect each managed
area with a separate mutex, but that would create trouble if, for
example, evicting from VRAM to managed GART.

/Thomas