Re: [PATCH 2/2] drm/vram-helper: Alternate between bottom-up and top-down placement

From: "Christian König" <christian.koenig@amd.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	Gerd Hoffmann <kraxel@redhat.com>
Cc: airlied@linux.ie, sam@ravnborg.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/vram-helper: Alternate between bottom-up and top-down placement
Date: Fri, 24 Apr 2020 08:56:10 +0200	[thread overview]
Message-ID: <d5c457e6-6808-2a00-fa21-65601abc00cf@amd.com> (raw)
In-Reply-To: <abd885fb-39e3-35e6-9104-2298ad73c2c6@suse.de>

Am 24.04.20 um 08:27 schrieb Thomas Zimmermann:
> Hi Christian
>
> Am 23.04.20 um 17:04 schrieb Christian König:
>> Hi guys,
>>
>> one thing you don't seem to have considered yet is that not setting the
>> top-down flag also won't get you the bottom-up approach, but rather the
>> best fit.
> Kind of unrelated: Would it pick the smallest free area that can hold a
> BO? IOW, would a small cursor BO fill up a small free area even if
> there's a much larger free area somewhere?

Yes, exactly that.

The bottom-up method searches for the lowest hole which can fit the 
requirements.

The top-down method searches for the highest hole which can fit the 
requirements.

Both of those walk the holes by the address index tree, but there is 
also the best method which looks at the holes by their size and tries to 
find the best fit.

The best method usually only needs a single tree walk instead of a 
linear search.

>> Am 23.04.20 um 15:57 schrieb Gerd Hoffmann:
>>>> But cursor BOs are small, so they don't make much of a difference. What
>>>> is needed is space for 2 primary framebuffers during pageflips, with one
>>>> of them pinned. The other framebuffer can be located anywhere.
>>> The problem isn't the size.  The problem is dynamically allocated cursor
>>> BOs can also fragment vram, especially if top-bottom allocation is also
>>> used for large framebuffers so cursor BOs can end up somewhere in the
>>> middle of vram.
>> Well maybe instead of a ping/pong approach between top and bottom use a
>> size based approach to place small BOs at the top and only the larger
>> ones at the bottom (or the other way around).
> That's what the current code does and it results in the OOM. Basically,
> there's a large BO in the middle of vram and the pageflip's destination
> BO does not fit before or after the large one.

Tough problem. No idea how to otherwise fix this without making the 
large BO moveable somehow.

Christian.

>
> Best regards
> Thomas
>
>> Cheers,
>> Christian.
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel