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

Michel Dänzer michel at daenzer.net
Thu Oct 30 01:41:44 PDT 2014


On 28.10.2014 20:10, 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.

Sent out a new patch 4 which nukes 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.

I recently made some changes in TTM and radeon to alleviate that 
particular issue, but the scan roaster does sound useful. Unfortunately, 
modifying TTM to use it is a bit too involved for me right now, any 
volunteers?


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer


More information about the dri-devel mailing list