linux - 突发写入 SD/USB 使我在嵌入式 Linux 上的时间关键型应用程序停滞不前

Question

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

我发现在超过一定的数据速率(大约 750kbyte/sec)时，我开始看到用户空间视频编写应用程序可能会停顿半秒，大约每 5 秒停顿一次。这足以导致内核驱动程序用完缓冲区 - 即使我可以增加缓冲区的数量，视频数据也必须与其他实时发生的事情同步(最好在 40 毫秒内)。在这 5 秒的“滞后尖峰”之间，写入在 40 毫秒内完成(就应用程序而言 - 我感谢它们被操作系统缓冲)

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

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

我在寻找两种线索:

1. 我如何才能阻止突发写入导致我的应用程序停滞 - 也许是进程优先级、实时补丁，或者调整文件系统代码以连续写入而不是突发写入？

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

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

更新:

• 安装文件系统 SYNC 会导致吞吐量太低。
• 可移动媒体是 FAT/FAT32 格式，并且必须是因为设计的目的是该媒体可以插入任何 Windows PC 并读取。
• 定期调用 sync() 或 fsync() 说，每秒都会导致定期停顿和 Not Acceptable 低吞吐量
• 我正在使用 write() 和 open(O_WRONLY | O_CREAT | O_TRUNC) 而不是 fopen() 等。
• 我无法立即在网上找到任何关于提到的“Linux 实时文件系统”的信息。链接？

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

Answer 1

根据记录，除了最极端的情况外，有两个主要方面似乎已经消除了所有问题。该系统仍在开发中，尚未经过彻底的酷刑测试，但运行良好(摸木头)。

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

另一方面是关注物理介质的最终写入吞吐量。为此，我一直在关注 Dirty 统计数据:由/proc/meminfo 报告。如果 Dirty: 爬升到某个阈值以上，我有一些粗略的现成代码来限制编码器，似乎模糊地工作。稍后需要进行更多测试和调整。幸运的是，我有很多 RAM (128M) 可以玩，给我几秒钟的时间来查看我的积压工作并顺利减少。

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