我正在从事一个嵌入式Linux项目，该项目将ARM9连接到硬件视频编码器芯片，并将视频写到SD卡或USB记忆棒中。该软件体系结构包括将数据读入缓冲池的内核驱动程序，以及将数据写入已安装的可移动设备上的文件的用户态应用程序。

我发现在一定的数据速率（大约750kbyte /
sec）以上时，我开始看到userland视频编写应用程序停顿了大约半秒钟，大约每5秒钟。这足以使内核驱动程序用尽缓冲区-
即使我可以增加缓冲区的数量，也必须将视频数据与实时进行的其他事情同步（最好在40ms之内）。在这5秒的“滞后尖峰”之间，写入在40ms内完成得很好（就应用程序而言-
我感谢它们被操作系统缓冲）

我认为这种延迟高峰与Linux将数据刷新到磁盘的方式有关-
我注意到pdflush设计为每5秒唤醒一次，我的理解是，这就是编写的内容。一旦停滞结束，userland应用程序便能够快速服务并编写缓冲区的积压（未溢出）。

我认为我正在写入的设备具有合理的最终吞吐量：从内存fs复制15MB文件并等待同步完成（并且USB记忆棒的光停止闪烁）使我的写入速度约为2.7MBytes /
sec。

我正在寻找两种线索：

1. 如何阻止突发写入停止我的应用程序-可能处理优先级，实时补丁或调整文件系统代码以连续写入而不是突发写入？

2. 如何使我的应用程序从写入积压和卡/棒的吞吐量方面了解文件系统的状况？我可以即时更改硬件编解码器中的视频比特率，这比丢弃帧或对最大允许比特率施加人为上限要好得多。

更多信息：这是一个200MHz的ARM9，当前运行基于Montavista 2.6.10的内核。

更新：

• 挂载文件系统SYNC会导致吞吐量太差。
• 可移动媒体是FAT / FAT32格式的，并且设计时必须确保该媒体可以插入任何Windows PC并读取。
• 定期调用sync（）或fsync（）表示，每秒会导致常规停顿和不可接受的吞吐量下降
• 我正在使用write（）和open（O_WRONLY | O_CREAT | O_TRUNC）而不是fopen（）等。
• 我无法立即在线找到有关上述“ Linux实时文件系统”的任何信息。链接？

我希望这是有道理的。关于stackoverflow的第一个嵌入式Linux问题？:)