[PATCH 2/2] drm/amdgpu: prevent command submission failures under memory pressure

[Marek Olšák]

On Fri, Sep 2, 2016 at 12:56 PM, Christian König
<deathsimple at vodafone.de> wrote:
> Am 02.09.2016 um 12:33 schrieb Marek Olšák:
>>
>> On Fri, Sep 2, 2016 at 9:38 AM, Christian König <deathsimple at vodafone.de>
>> wrote:
>>>
>>> Am 01.09.2016 um 16:33 schrieb Deucher, Alexander:
>>>
>>>> return r; > + > + return -ENOMEM; > +}
>>>
>>> Unreachable code. Other than that looks good.
>>>
>>>
>>> Ups, indeed just a merge error.
>>>
>>> With that fixed: Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
>>>
>>> Thanks for the review, I've just pushed the resulting patches to
>>> amd-staging-4.6.
>>>
>>> Marek you might want to try and raise the limits now how much VRAM can be
>>> used by a single command submission. If I remember correctly that was
>>> rather
>>> conservatively.
>>
>> I would beg to differ. Just to simplify the calculation, let's assume
>> there are not allocations in GTT (in practice there are very few, so
>> it's very close to the reality). If you take the memory used by all
>> VRAM buffers in CS, the limit for that is "VRAM size + (GTT size *
>> 0.7)".
>>
>> If you have 4GB VRAM and 4GB GTT, Mesa allows per-CS VRAM usage to be 6.8
>> GB.
>>
>> If you have any GTT buffers there, you just subtract from that. For
>> example, if you have 100MB GTT usage, the VRAM limit is 6.7 GB.
>>
>> Does that sound conservative to you?
>
>
> Not at all :)
>
> But I clearly remember that you noted that you can't allocate more than 75%
> of VRAM in one CS without running into problems sometimes. Is that already
> fixed?

No, I can allocate all of VRAM (actually Mesa can't allocate VRAM
"physically", only the CS ioctl can reserve it for its time window).

The problem I saw was the following. GEM_CREATE or the CS ioctl (I
don't remember which one) had a great chance of failing if 1 buffer
has the size of 50% of VRAM. You can have thousands of tiny buffers
being able to use close to 100% of VRAM, but you can't have 1 buffer
whose size is only 50%. After that discovery, we speculated that the
number of pinned buffers (=CRTCs) may have had something to do with
that.

Marek