1. 使用内核性能剖析工具可以分析系统在那个函数比较花费时间。。工具是 Kernrate。。。。
2. 在Dpc/Dispatch级别上运行的代码，有一个重要的限制是： 不能等待任何对象，因为等待对象会导致新的线程调度。同时带来的副作用是不能有页面错误。
所以这些代码必须运行在非分页内存中。（为什么有这样限制还没想明白？）
3. 中断对象。。充分证明了windows就是对象的集合。。
a. 设备驱动程序可以为他们的设备注册ISR（怎么注册？要看 source code ）这个就是中断对象。中断对象中包含了 服务例程的起始地址(routine address)
中断对象运行的IRQL 。。 中断对象的自旋锁。 还有一些从中断处理模板code 放在 DispatchCode【106】变量中。
b. 在Dispatchcode中调用了 中断分发器。。 内核中中断分发器的例程： KiInterruptDispatch （只适合一个注册了一个中断对象的中断向量） 和KiChainedDispatch (链式分发 。。）
7. 中断控制流：
7. 中断对象的结构
typedef struct
{
.....
ServiceRoutine
ServiceContext
SpinLock
IRQL
DispatchCode【106】;
};
将ISR与只能中断级别联系起来的 函数： IoConnectInterrupt。
8 软件中断
主要包括：
线程分发 DPC 定时器到期 APC 异步I/O 。
DPC机制
我理解的DPC机制：
因为设备驱动的中断服务例程都工作在DPC/Dispatch级别之上。。。这个时候为了使得本来应该在ISR中完成但是又不是很紧迫的任务 放到 DPC队列中，而ISR执行完紧迫任务后，便触发一个软中断，（设置PRCB的标志位），然后中断服务例程便返回了。。 等处理器的IRQL降下来的时候，便去检查DPC队列，如果有请求 ，便执行 。
DPC请求都对应一个DPC对象。。。该对象中最重要的是 该DPC需要执行的系统函数地址 。。
线程分发 。。。 时钟中断。。。 都是采用 DPC机制完成的。。
关于上面的两个部分感觉原著上说的挺好：
关于DPC机制的实现 ：
http://book.csdn.net/bookfiles/1044/100104431308.shtml 这个ReactOS的实现 。。 我感觉 和windows的真正的实现有些出入 。。
要调试 看下windows怎么实现的。