Gerd Knorr wrote:
>
> > > It makes sense to me to pass the buffer on QBUF, not QUERYBUF, and no
> > > new REQBUFS=0 semantics is required. I understand the desire to save
> > > locking and unlocking the memory each time it is used, but don't think
> > > it's a significant overhead considering the memcpy() that is being
> > > avoided.
> >
> > I don't agree here. If I remember correctly, the process of locking
> > down the user memory can be VERY expensive. Remember - it's got to be
> > paged in if in is not already present in physical memory.
>
> I don't see the paging in as a big problem. If you do streaming
> capture your buffers should'nt get swapped out as they are accessed
> all the time (as long as you are using the same set of buffers).
If you're doing streaming capture with say 30 buffers (1 second), and
writing to file, I am pretty sure you would end up having for buffers
swapped out fairly regularly.
> Remaining overhead is page table lookups + (for bt848) risc code
> generation. Even that can be reduced. We could use a flag for that.
> If a application plans to reuse that buffer some hint flag can be set,
> and the driver can keep the buffer locked down then. Not forever
> (that would allow a nice DoS), but for - say - a second. Long enouth
> that we don't have to lock it again if the app does streaming
> capture.
>
> Gerd
Now this is starting to look a lot uglier than simply modifying the
REQBUFS semantics to allow freeing of the buffers explicitly (which you
still require anyway).
-justin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
