old time summary

1. 从无锁到RCU

方案一, 使用atomic实现mapping_array, 标识当前所有可用CPU的占用情况.

关闭抢占, 避免进程在不同CPU之间跳转.

使用PERCPU, 使CPU各自分别维护独占的资源, 避免相互冲突.

这种方案可以最大限度上地使用CPU资源, 但只有在系统底层才能实现.

方案二, 锁和资源mask

使用mask_array保护资源被分配到特定进程后, 不再占用全局锁.

整体思路就是尽量限制锁的控制范围以及使用锁的时间. 这首先要求资源可以被分割使用.

另一种选择: RCU

RCU基本原理:

1. CPU每次读写内存单元小于等于CPU字长时, 所执行的操作为原子操作

2. 复制某些数据结构的系统调用开销要小于进程切换

限制:

1. 用于读次数远远大于写次数的场合

2. 接口只对list, rbtree等特定数据结构做了实现

RCU文档:

RCU list实现的大致原理:

2. 简化操作流程, 如linux scsi和scst

若干年前, scsi大概是这样的:

所以2.4内核中的scsi是这样的:

后来scsi协议变成了这个样子:

于是现在内核中的scsi变成了这个样子:


另一种选择, scst:

使用do_page()的底层接口直接分配内存页

使用scatter_list实现散列读写

只实现scsi target, 简化对scsi 协议的实现

scsi cmd的解析仍由系统scsi_lib.c完成

scst只是对kernel scsi up level的简化实现, 并不是完全替代.

scst.sourceforge.net/

en.wikipedia.org/wiki/SCST

整体思路: 对于像SCSI协议这样和系统底层密切相关的模块, 在系统中被大量调用, 很难做到剥离出系统进行单独简化. SCST的思想就是仅实现target功能, 并对下层的驱动函数提供专用的scst driver. 但同时仍大量复用内核SCSI模块的代码, 以简化SCST自身的实现复杂度.

3. 硬件加速, 目前主流网络设备的通用做法

专用网络设备, 针对网络部分路由解析/处理进行特定的优化.

第一层, linux tcp route table(fib), 内核网络层实现

第二层, 加速tcp flow table

第三层, 硬件FPGA加速flow table

局限: 类似的优化基本是依靠特定硬件去完成原有软件完成的功能. 但硬件的成本还没有低到可以在网络中的所有节点上都部署这样的加速功能, 通常的非关键节点也不需要.

4. 云计算

问题:

功能大都在用户态实现, 对系统底层要求整体上的性能提升, 而不仅仅是某个模块.

应用层的功能没有显著的特征, 需要在实际应用环境中大量测试来找出系统瓶颈.

软件层面上的算法在提升效率上效果不明显.