Gerd Knorr wrote: ... > > > 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). OK - then how about keep the REQBUFS(0) (or something similar), and scrap this stuff about locking down a buffer for 1 second, etc. That is starting to look like a horrible kludge, with a lot that can go wrong. Could you possibly include a short draft of your spec, just so that I can see it all together (possibly add how you want to handle multiple planes) - I would really appreciate it. Thanks, -justin
