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
