Bursty写信给SD/USB拖延我在嵌入式Linux上的时间关键应用程序

我正在开发一个嵌入式Linux项目,它将ARM9连接到硬件视频编码器芯片,并将视频写入SD卡或USB记忆棒.软件体系结构涉及将数据读入缓冲池的内核驱动程序,以及将数据写入已安装的可移动设备上的文件的用户空间应用程序.

我发现超过一定的数据速率(大约750kbyte/sec),我开始看到用户视频写入应用程序停止大约半秒钟,大约每5秒钟.这足以导致内核驱动程序用完缓冲区 - 即使我可以增加缓冲区的数量,视频数据也必须与实时进行的其他事情同步(理想情况下在40ms内).在这5秒的"滞后峰值"之间,写入在40ms内完成(就应用程序而言 - 我很欣赏它们被OS缓冲)

我认为这种滞后峰值与Linux将数据刷新到磁盘的方式有关 - 我注意到pdflush旨在每5秒唤醒一次,我的理解是这将是写作的内容.一旦停止结束,用户态应用程序就能够快速服务并写入积压的缓冲区(没有溢出).

我认为我写的设备具有合理的最终吞吐量:从内存fs复制15MB文件并等待同步完成(并且usb棒的灯停止闪烁)给了我大约2.7MBytes/sec的写入速度.

我正在寻找两种线索:

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

如何让我的应用程序了解文件系统在写入积压和卡/棒的吞吐量方面发生了什么？我能够动态地改变硬件编解码器中的视频比特率,这比丢帧更好,或者在最大允许比特率上强加一个人工上限.

更多信息:这是一个200MHz ARM9,目前运行基于Montavista 2.6.10的内核.

更新:

挂载文件系统SYNC会导致吞吐量太差.

可移动媒体是FAT/FAT32格式,必须符合设计目的,媒体可以插入任何Windows PC并读取.

定期调用sync()或fsync()说,每秒都会导致常规停顿和不可接受的吞吐量不佳

我使用write()并打开(O_WRONLY | O_CREAT | O_TRUNC)而不是fopen()等.

我无法立即在网上找到有关上述"Linux实时文件系统"的信息.链接？

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

事实证明,除了最极端的情况外,似乎已经消除了所有问题的两个主要方面.该系统仍在开发中,尚未经过彻底的折磨测试,但工作得相当好(触摸木材).

最大的胜利来自于使用户地作家应用程序多线程.对write()的调用有时会阻塞:其他进程和线程仍在运行.只要我有一个服务于设备驱动程序的线程并更新帧计数和其他数据以与正在运行的其他应用程序进行同步,就可以在几秒钟之后缓冲并写出数据,而不会违反任何截止日期.我先尝试了一个简单的乒乓双缓冲,但这还不够; 当文件系统消化了写入时,小缓冲区将被淹没,而大缓冲区只会导致更大的暂停.在线程之间排队的10个1MB缓冲池现在运行良好.

另一方面是关注物理媒体的最终写入吞吐量.为此我要关注stat Dirty:由/ proc/meminfo报告.如果Dirty:攀升到某个阈值以上,我有一些粗略和准备好的代码来限制编码器,似乎模糊地工作.稍后需要进行更多测试和调整.幸运的是,我有很多RAM(128M)可以让我几秒钟看到我的积压建立并顺利减速.

如果我发现我需要做任何其他事情来处理这个问题,我会尽量记住回弹并更新这个答案.感谢其他的回答者.