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@xxxxxxx>
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
