第五章 第二部分端节点算法学.ppt

5.7 扩展到拷贝之外 利用load和store之间的空周期做累加计算，不需额外开销，拷贝循环可以扩展到包括检查和计算。 Integrated Layer Processing（ILP） 整合层次处理（ILP）的主要思想： 对同一个数据包进行多种数据操作时，将这些操作整合在一个循环中，避免对包中的数据进行多次的读和写（P1）。 整合层次处理会有什么问题？ ILP面临的问题 问题一： 不同操作需要的信息一般来自不同的层次，将不同层次的代码整合在一起而不牺牲模块化特性极其困难 问题二： 不同操作可能需要在不同长度的数据块上以及数据包的不同部位进行。 问题三： 有些操作可能是相互依赖的。比如，如果数据包的TCP检查和验证失败，就不应当对包进行解密操作。 ILP面临的问题（续） 问题四： 过分提高整合度可能降低代码的局部性，增大指令cache的miss率，反而产生不良的后果。 结论： ILP很难实现（问题1~问题3） ILP可能性能不佳（问题4） ILP可能完全没有必要（若包数据需要被处理几次，则数据很可能驻留在cache中） 5.8 扩展到数据操作之外 消除数据拷贝和整合数据操作，其技术共同点都是避免冗余的读/写操作，以减少对内存总线的压力。 还有哪些因素会影响内存总线的使用呢？ Cache的使用效率 DMA或PIO的选择 5.8.1 有效使用 I-cache 处理器包含一个或多个数据cache，以及一个或多个指令cache： 一般而言，包数据几乎不能从 d-cache 获得好处 处理数据包需要的状态可以从d-cache 获益 处理数据包的程序代码可以从 I-cache 获益 代码和状态都可能竞争内存带宽，相比而言，代码对内存带宽的竞争更严重： 处理一个包需要的状态一般较小，比如一个连接表项 协议栈处理的代码大得多，而I-cache的容量一般很小 I-Cache的实现特点（1） 大多数处理器使用直接映射的I-cache： 内存地址的低位比特用来检索I-cache条目； 如果高位比特匹配，直接从I-cache返回内容； 若不匹配，进行一个主存访问，用新的内容替换原来的条目。 问题： 被映射到I-cache同一位置的代码会被轮流替换出去，即使它们都是经常使用的代码。 I-Cache的实现特点（2） 每一条I-cache包含多条指令： 当取一条指令时，同一个代码块中的全部指令都会被读入。（基于空间局部性假设而优化） 问题： 不常用的代码会被读入I-cache，如果它与常用代码在一个块中。 举例 许多网络代码包含错误检查，比如： if error E do X, else do Z 虽然 Z 几乎从不被执行，但是编译器通常会将 Z 的代码紧跟在 X 的后面。 如果 X 和 Z 位于同一个指令块中，取经常使用的代码 X，会把不经常使用的代码 Z 也取进来，浪费了内存带宽和cache空间。 问题 指令cache没有很好地反映时间局部性： 经常使用的代码不一定在cache中：由一个不完美的映射函数引起 不常使用的代码可能被经常调入cache：由cache对空间局部性的优化引起 怎么解决这个问题呢？ 问题与解决方案 指令cache没有很好地反映时间局部性： 经常使用的代码不一定在cache中：由一个不完美的映射函数引起 不常使用的代码可能被经常调入cache：由cache对空间局部性的优化引起 解决办法： 重新组织代码，将经常使用的代码连续放置 运用原则 代码在内存中的布局是一个可以利用的自由度（P13）。 通过安排代码在内存中的位置优化常见情形（P11），使得最常使用的代码驻留在I-cache中 新的问题 处理包的协议代码肯定无法全部装入指令cache： I-cache的容量非常有限 计算机上的所有程序都要竞争I-cache 问题： 每处理一个包，就要将全部的协议代码装入指令cache一次，效率太低！！ 局部性驱动的协议层处理 基本思想： 每个协议层一次处理多个包，分摊装载 I-cache的开销 每一批处理的包数量越多，I-cache的使用越高效 具体实现时，应能动态调整批处理的大小 软件工程方面的考虑 代码重新组织可以让编译器来做： 程序员对不常使用的代码分支进行标注，由编译器为I-cache重新组织代码。 局部性驱动的协议层处理需修改层间通信方法： 如果协议代码使用一个过程调用将数据包传递给上（下）一层，则代码修改为将数据包加入上（下）一层的一个包队列中。 当一个协议层被调用时，从自己的读队列中取数据包，直至队列取空。 5.8.2 DMA还是PIO PIO需要CPU参与，完成内存-外设之间的数据传输需要使用内存总线两次 DMA不需要CPU参与，且内存-外设之间的数据传输只需要使用内存总线一次