我正在开发一个嵌入式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的内核.
更新:
我希望这是有道理的.stackoverflow上的第一个嵌入式Linux问题？:)