Justin Schoeman wrote:
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.
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).
<Rant>
When it comes to getting the best performance possible, "ugly" is
inevitable.
A lot of control gets pushed to user space, and improper programming
from user space is going to compromise the system. That's the price
you pay to get the best performance. I'm not sure even a 1sec
time-out on the locks would guarantee recovery from bad/malicious
programming.
But, this portion of the API is being developed for performance, so it
must provide for the best performance possible; and that includes
giving the user control over (un)locking pages.
I remember a high-speed communications driver (many years back) that
demanded bus mastering to user space. On SCO Unix, we found that
scatter-gather lists of the users locked-down memory was still too
slow because the device would interrupt at the end of each
scatter-gather element, requesting the next element. SCO had a kernel
routine to allocate physically contiguous locked-down memory at boot
time: we used that to grab a huge chunk of memory, and provided an API
call that allowed the user to map this memory into user space. That's
UGLY; but, we got the best possible performance. (The Alpha has the
best solution: its hardware scatter-gather registers make the buffers
look contiguous to a bus-mastering device.)
In this portion of the API, performance is the biggest requirement.
We can make it as clean and elegant as possible, but we have to err on
the side of performance. Eventually, cleaner solutions will come
about through changes in the hardware and kernel.
</Rant>
Chris
