多媒体平台上的设备-驱动程序性能注意事项
本文提供关于编写 Microsoft Windows 家族操作系统的设备驱动程序的信息。为驱动程序开发人员提供最小化驱动程序行为对多媒体应用程序的负面影响的指南。
On This Page
 | 简介 |
| 驱动程序行为如何影响多媒体应用程序 |
| 测量 ISR 和 DPC 执行时间 |
| 在 PASSIVE_LEVEL 级别上执行 |
简介
本文提供关于编写 Microsoft Windows 家族操作系统客户端版本的内核模式设备驱动程序的信息。
设备-驱动程序行为能够对多媒体应用程序的性能带来显著影响。显然，驱动程序开发人员最小化任何潜在的负面影响非常重要。为此，本文提供关于驱动程序行为如何影响 Microsoft Windows 环境的信息和最小化这些影响的技巧。这些信息和技巧包括：
| • | 中断服务例程 (Interrupt Service Routine, ISR) 或者延迟过程调用 (Deferred Procedure Call, DPC) 应该消耗的最大处理器时间。 |
| • | 如何测量 ISR 和 DPC 执行时间。 |
| • | 在中断请求级别 (IRQL) PASSIVE_LEVEL 上驱动程序如何执行。 |
驱动程序行为如何影响多媒体应用程序
ISR 和 DPC 会消耗活动线程的处理时间。如果此线程是一个多媒体线程，则多媒体应用程序可能会丢失时间期限，将错误的内容呈现给用户或者在错误的时间呈现正确的内容。例如，DVD 播放应用程序必须每隔 33 毫秒装载、解码和显示一个视频帧。如果解码线程花费了太多时间来运行一个长的 DPC，那么该应用程序就无法满足此时间期限。结果，用户会感觉画面不流畅。
要交付高质量的音频和视频，多媒体应用程序必须考虑系统上的每个驱动程序在高于 PASSIVE_LEVEL 的 IRQL 级别上消耗的处理时间量。但是，如果 IRQL 一直高于 PASSIVE_LEVEL，那么驱动程序行为将被定义为 unpredictable。由于当前在 Microsoft Windows 环境中的驱动程序行为不可预测，多媒体应用程序常常会提供较差的体验。相比之下，专用机顶盒和游戏系统能够保持可预测的环境，因为它们使用了行为良好的专用驱动程序。因此，这些系统可以支持高质量的多媒体应用程序 - 即使平台硬件与运行 Microsoft Windows 操作系统的硬件相同。
注意：
本文描述的指南也适用于服务器系统，即使这些系统不运行多媒体应用程序。对于服务器系统，提高 Microsoft Windows 环境的可预测性非常重要，这能够保证含有时间期限的其他应用程序（例如用户界面）能够正确执行。
改进用户的多媒体体验
Microsoft 正在将一些能够改善用户多媒体体验的功能合并到 Widnows Vista 中，支持用户确定发生停顿的原因。用户可以识别消耗大量处理时间的设备，并通过一些方式重新配置、禁用或者更换设备及其驱动程序，以获得流畅的多媒体体验。
ISR 与 DPC 行为指南
因为过多的处理时间 的定义是主观的，所以本节中介绍的指南源于多媒体应用程序和其他时间密集型应用程序的要求。这些指南适用于具有中等功能的系统，这类系统的包含一个主频不超过 900 MHz 处理器、内存不超过 512 MB 、系统总线频率低于 133 MHz。
要获得可预测和有边界的多媒体应用程序环境，所有设备驱动程序必须坚持下列原则：
| • | 在带有 1 GHz 处理器的系统上，在每个 2 毫秒的周期之中，驱动程序的时间总和不应超过 400 微秒。该原则与具体的驱动程序无关，因为单个设备不能控制或影响其他设备的行为，但是值得注意的是，应当保证这个系统级原则明白无误，并保持单个驱动程序行为的透明性。 |
| • | 一个 ISR 消耗的时间绝不应超过 25 微秒。这意味着 ISR 应当能够清除当前发出 IRQ 的所有硬件信号、排队等候要求的 DPC，并在 25 微秒内返回。消耗时间此时间量的工作都应该在 DPC 级别上完成。 |
| • | 单个 DPC 消耗的时间绝不应超过 100 微秒。DPC 消耗时间过长会造成留给其他处理的时间太少，无法在应用程序的时间期限之内完成。耗时超过 100 微秒的任何必需工作都应该由一个线程完成。 |
| • | 驱动程序或线程执行的操作阻碍其他驱动程序的时间不应该超过 25 微秒，因为这样做与运行非常长的 ISR 具有同样的后果。阻碍驱动程序的操作包括持有自旋锁、执行 CLI 或 STI 指令、提高 IRQL 和屏蔽中断。（无论 CLI 和 STI 指令消耗的时间有多短，它们都应该仅用于极其罕见的情形。） |
| • | 如果可能的话，调用 KeDelayExecutionThread 函数，而不是 KeStallExecutionProcessor。 如果必须调用后者，那么单次调用的延迟或者相邻调用的累积延迟不应该超过 100 微秒。 |
坚持上述原则是 Microsoft Windows 能够成功地作为家庭多媒体平台的重要原因。如果系统载入的驱动程序不满足这些原则，那么该系统不适用于多媒体场景。
测量 ISR 和 DPC 执行时间
Microsoft 向 Microsoft Windows XP Service Pack 2 (SP2) 中添加了支持报告 ISR 和 DPC 执行时间的基础结构。可以在驱动程序开发期间使用该基础结构来测量和优化驱动程序的行为。下节简短描述如何使用在该基础结构上构建的事件跟踪工具。
注意：
您可以在 Microsoft 平台 SDK 的“事件跟踪”一节找到关于使用该基础结构及其工具的完整文档。
事件跟踪工具
您可以使用 Tracelog.exe 和 Tracerpt.exe 工具来利用事件跟踪基础结构。Tracelog.exe 开启或关闭跟踪数据收集，而 Tracerpt.exe 将跟踪日志文件转换为以逗号分隔的文本格式文件并生成文本格式的汇总文件。
要收集与驱动程序相关的数据：
1. | 运行 tracelog -start -f kernel.etl -b 64 -UsePerfCounter -eflag 8 0x307 0x4084 0 0 0 0 0 0，开始记录下列执行时间：进程、线程、映像载入、线程上下文交换、DPC、计时器 DPC 和 ISR。 |
2. | 运行 tracelog -stop 停止记录。 |
3. | 运行 tracerpt kernel.etl，在 Summary.txt 中生成事件汇总，在 Dumpfile.csv 中生成全文本跟踪记录。 |
4. | 运行 tracerpt kernel.etl -report 生成文本报告，汇总 DPC 和 ISR 执行时间。 |
Dumpfile.csv 的第一行以文本 "Event Name" 开始，还包含报告的列标题。
在 Dumpfile.csv 中，DPC、计时器 DPC 和 ISR 事件具有下列格式：
PerfInfo, (DPC|ISR|计时器 DPC), 未使用时间, 结束时间, 内核时间, 用户时间, 开始时间, 例程时间, 未使用时间, 未使用时间
要获得例程地址指向的 DPC、计时器 DPC 或者 ISR 的大概执行时间，可以从结束时间减去起始时间。
在 Dumpfile.csv 中，上下文交换事件具有下列格式：
线程, ContxtSwap, 未使用时间, 结束时间, 内核时间, 用户时间, 新线程 id, 旧线程 id, 新线程优先级, 旧线程优先级, , , , 1, 旧线程状态, 旧线程理想处理器数目, 未使用时间, 未使用时间
注意：
关于各个事件的更多信息，请参阅 Microsoft 平台 SDK 的“事件跟踪”一节中的“MOF 类”。
在 PASSIVE_LEVEL 级别上执行
如果驱动程序必须执行的工作将会导致其超出时间限制，那么驱动程序应该在 PASSIVE_LEVEL 级别上执行这些工作。在 PASSIVE_LEVEL 级别上执行工作具有两个选项：驱动程序可以创建专用线程来执行耗时较长的工作项，也可以使用系统提供的内核模式工作线程。
尽管创建专用线程是一种更加灵活的方法，但是从系统的角度来看，利用系统工作线程更加简单和高效。
关于驱动程序如何创建驱动程序专用线程和系统工作线程的更多信息，请参阅 Microsoft DDK 中的“线程对象”一节。