[PATCH] [RFC]drm/ttm: fix scheduling balance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 01/25/2018 06:30 PM, Christian König wrote:
> Am 25.01.2018 um 17:47 schrieb Thomas Hellstrom:
>> On 01/25/2018 03:57 PM, Thomas Hellstrom wrote:
>>> On 01/25/2018 10:59 AM, Chunming Zhou wrote:
>>>> there is a scheduling balance issue about get node like:
>>>> a. process A allocates full memory and use it for submission.
>>>> b. process B tries to allocates memory, will wait for process A BO 
>>>> idle in eviction.
>>>> c. process A completes the job, process B eviction will put process 
>>>> A BO node,
>>>> but in the meantime, process C is comming to allocate BO, whill 
>>>> directly get node successfully, and do submission,
>>>> process B will again wait for process C BO idle.
>>>> d. repeat the above setps, process B could be delayed much more.
>>>>
>>>> add a mutex to gerantee the allocation sequence for same domain. 
>>>> But there is a possibility that
>>>> visible vram could be evicted to invisilbe, the tricky is they are 
>>>> same domain manager, so which needs a special handling.
>>>>
>>>> Change-Id: I260e8eb704f7b4788b071d3f641f21b242912256
>>>> Signed-off-by: Chunming Zhou <david1.zhou at amd.com>
>>>
>>> I think this is a good approach, however there are two things that 
>>> IMO needs fixing. [...]
>>
>> Thinking a bit more about this, the end result would be that typical 
>> "C" processes would get an unfair amount of GPU scheduling.
>> Isn't it actually a scheduler's task outside of TTM to mitigate this?
>
> Yes, exactly the reason why I rejected this. I actually considered 
> moving the whole evicting to a background workitem.

Ah,I should've read up on the following emails, Sorry about that.

Thanks,
Thomas



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux