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
