> > 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. Linux does'nt start swapping that fast. If it does you don't have enouth memory. > > 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). The point isn't that you save the REQBUFS(0). The point is we can be more flexible (the application _can_ reuse buffers, but this is not _required_) without a major performance hit (the application can hint the driver that it plans to reuse the buffer and it is worth keeping it locked in memory to save some CPU time / avoid swapout / whatever). Gerd -- Get back there in front of the computer NOW. Christmas can wait. -- Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel
