ioctl的性能瓶颈

上周发现我的一个程序在测试并发压力时，在rhel4上性能不错但在rhel5上性能却下降很厉害，非常诡异。我们基本相信redhat不会有什么问题，那八成是我的kernel module写的有问题，于是我把module里对不同kernel版本的判断拿掉，再跑，还是性能低。这下要命了，如果是某些kernel module的接口变了，那查起来就费时间了。

还是史峰高超，他发现了随着并发的增加，性能会进保持在一个“高原”上，于是让我做个小实验：写一个程序，就调用ioctl故意触发module，多跑几个实例。这下问题明显了：这个测试程序，不管启动多少个实例，他们加起来耗费的CPU基本就是100%左右（甚至有时还低），问题明朗化了——看来ioctl八成有锁，多进程不能同时调用进去。

于是看kernel代码，原来从2.6.11开始，file_operations除了ioctl，还增加了一个接口——unlocked_ioctl（rhel5用的是2.6.18 kernel）。于是改我的module，原先实现ioctl接口，现在改为实现unlocked_ioctl，性能一下子上去了。感谢史峰！

性能问题解决了，但是还存有疑问，因为我发现rhel4（2.6.9 kernel)上的ioctl也是加了“大内核锁”的：

lock_kernel()

ops->ioctl()

unlock_kernel()

这太不公平了，rhel5上有lock_kernel，ioctl性能大降，rhel4u上也有lock_kernel，ioctl咋就性能还凑合呢？

查了ULK3，原来有个说法：大内核锁在2.6.11之前是一个高效的spinlock，而在此之后，由于大量的kernel代码都慢慢弃用大内核锁（比如改用unlocked_ioctl），大内核锁的实现就变为了可能引发睡眠的mutex（睡眠就睡眠呗，反正大内核锁现在处于“逐步弃用“的阶段，以后就没了），所以性能有退化。