I'm working on an embedded Linux video recorder application which writes MP4 format video to a file (on FAT format SD card).
Some complicating factors are that the video and audio data come from hardware codecs which have to be serviced with low latency, and must write into DMA-capable buffers.
At the moment for the output file I use open() and write(), but find that write() can take hundreds of milliseconds to return when the system is under load, so my writes are done in a separate thread.
As it stands I copy data from the (small, limited number) DMA buffers to a multi-megabyte malloc'd circular buffer, then write() from that in another thread. This means I'm doing at least two copies, once into the app buffer, and once into the system buffer cache.
I am considering trying O_DIRECT writes to avoid a copy, but am interested in any comments. I note that Robert Love comments that O_DIRECT is terrible but does not say why.
On the flip side, I would also be interested if anyone knows a way to get write() to not stall for longish periods of time (AIO?), then I could use the buffer cache as Linus intended.
This question is not unrelated to my very old question about write stalls.
If this is really an embedded product in that you control your driver source, I'd seriously looking into mmap'ping the memory to allow the user process to access the same memory as the device driver and avoid all those copies.
And here is a sample implementation of driver memory being shared with a userspace process using mmap.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With