Re: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF

[Nicolas Dufresne <nicolas@ndufresne.ca>]

I'd like to revive this discussion.

Le lundi 01 août 2016 à 12:56 +0200, Hans Verkuil a écrit :
> > 
> > Hans, Marek, any opinion on this ?
> 
> What is the use-case for this? What you are doing here is to either free all
> existing buffers or reallocate buffers. We can decide to rely on refcounting,
> but then you would create a second set of buffers (when re-allocating) or
> leave a lot of unfreed memory behind. That's pretty hard on the memory usage.
> 
> I think the EBUSY is there to protect the user against him/herself: i.e. don't
> call this unless you know all refs are closed.
> 
> Given the typical large buffersizes we're talking about, I think that EBUSY
> makes sense.

This is a userspace hell for the use case of seamless resolution
change. Let's say I'm rendering buffers from a V4L2 camera toward my
display KMS driver. While I'm streaming, the KMS driver will hold on
the last frame. This is required when your display is sourcing data
directly from your DMABuf, because the KMS render are not synchronized
with the V4L2 camera (you could have 24fps camera over a 60fps
display).

When its time to change the resolution, the fact that we can't let go
the DMABuf means that we need to reclaim the memory from KMS first. We
can't just take it back, we need to allocate a new buffer, copy using
the CPU that buffer data, setupe the DMABuf reference. that new buffer
for redraw and then releas

This operation is extremely slow, since it requires an allocation and a
CPU copy of the data. This is only needed because V4L2 is trying to
prevent over allocation. In this case, userspace is only holding on 1
of the frames, this is far from the dramatic memory waste that we are
describing here.

regards,
Nicolas