[PATCH 2/2] dma-buf: cleanup shared fence removal

[Koenig, Christian]

Am 28.06.19 um 16:38 schrieb Daniel Vetter:
[SNIP]
>>>>> - when you submit command buffers, you _dont_ attach fences to all
>>>>> involved buffers
>>>> That's not going to work because then the memory management then thinks
>>>> that the buffer is immediately movable, which it isn't,
>>> I guess we need to fix that then. I pretty much assumed that
>>> ->notify_move could add whatever fences you might want to add. Which
>>> would very neatly allow us to solve this problem here, instead of
>>> coming up with fake fences and fun stuff like that.
>> Adding the fence later on is not a solution because we need something
>> which beforehand can check if a buffer is movable or not.
>>
>> In the case of a move_notify the decision to move it is already done and
>> you can't say oh sorry I have to evict my process and reprogram the
>> hardware or whatever.
>>
>> Especially when you do this in an OOM situation.
> Why? I mean when the fence for a CS is there already, it might also
> still hang out in the scheduler, or be blocked on a fence from another
> driver, or anything like that. I don't see a conceptual difference.
> Plus with dynamic dma-buf the entire point is that an attached fences
> does _not_ mean the buffer is permanently pinned, but can be moved if
> you sync correctly. Might need a bit of tuning or a flag to indicate
> that some buffers should alwasy considered to be busy, and that you
> shouldn't start evicting those. But that's kinda a detail.
>
>  From a very high level there's really no difference betwen
> ->notify_move and the eviction_fence. Both give you a callback when
> someone else needs to move the buffer, that's all. The only difference
> is that the eviction_fence thing jumbles the callback and the fence
> into one, by preattaching a fence just in case. But again from a
> conceptual pov it doesn't matter whether the fence is always hanging
> around, or whether you just attach it when ->notify_move is called.

Sure there is a difference. See when you attach the fence beforehand the 
memory management can know that the buffer is busy.

Just imagine the following: We are in an OOM situation and need to swap 
things out to disk!

When the fence is attached beforehand the handling can be as following:
1. MM picks a BO from the LRU and starts to evict it.
2. The eviction fence is enabled and we stop the process using this BO.
3. As soon as the process is stopped the fence is set into the signaled 
state.
4. MM needs to evict more BOs and since the fence for this process is 
now in the signaled state it can intentionally pick the ones up which 
are now idle.

When we attach the fence only on eviction that can't happen and the MM 
would just pick the next random BO and potentially stop another process.

So I think we can summarize that the memory management definitely needs 
to know beforehand how costly it is to evict a BO.

And of course implement this with flags or use counters or whatever, but 
we already have the fence infrastructure and I don't see a reason not to 
use it.

Regards,
Christian.