> > - we do a copyfd(smallfile,framebuffer), in which copyfd()
> > instructs the capture-buffer DMA being done to the page-cache.
> > (this happens inside the kernel, the driver doesnt even notice
> > much from this)
>
> Well we can't do that yet because I can't just grab and pin 2Mb of page
> cache pages, at least we don't have nice clean API's for it and to clean
> up the cache afterwards.
this is a different issue, specific to video-capture. First, IO is so fast
that intermediate buffering grows easily into megabytes. Also there is a
RT component: unlike a disk, a camera cannot sustain unlimited IO delays.
[there are some other such applications too, like particle experiments
where you simply cannot instruct Nature to 'hang on for a second', but
it's typically rare and a special application group]
I think it's perfectly correct in this case to use mlock(), but the goal
is not to pin down pages as a basic mechanizm, but to guarantee bandwith.
(i assume the capture card can do at least page granularity scatter-gather
DMA?)
(since it's video-capture, mlock() should not be much of an issue, the
card is a controlled resource anyway. If in the future we will have video
capture hardware that can provide more finegrained resource sharing, we
will probably have to provide guaranteed bandwith services)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/