将软中断tasklet改为任务队列解决CPU使用率大的问题

einsn

    公司无线网卡驱动以前没有在2.4.19下的内核跑过，自己对驱动的源码也没有好好研究，上上周根据客户的要求，先把网卡驱动在X86平台的2.4.19下跑起，自己搞的很狼狈；为了实验在每个版本的内核是否可以跑起来，我在我电脑上装了RedHat8，并在RedHat8的基础上升级了2.4.19，2.4.20，2.4.20-8，2.4.21，2.4.22，光编译内核的时间就不知道花了多少时间。最后得出结论，公司的无线网卡只能在2.4.20-8及以后的版本上运行。通过比较发现，2.4.20-8及以后版本的USB部分EHCI控制器驱动改动比较大。后来我直接把2.4.20-8的EHCI驱动直接移植到2.4.19下，修改了几个编程错误及警告，最后加载进来，一切OK！呵呵，这关总算混过去。
    其实客户的问题根本与X86平台没有关系，客户的平台是嵌入式的ARM9平台，板上是芯片自带的USBOTG控制器，并且主机驱动是由芯片厂家写好的，可以说与标准的EHCI很不同，而且在这个芯片平台与X86平台表现出来的症状完全不同。我把X86下修改过的文件发给客户后，客户说根本没办法使用。最后客户那边寄了个平台过来。网卡驱动编译都很顺利，但是到了打开网卡时（执行ifconfig ethX up），会出现控制台反应缓慢现象，用top命令查看了一下进程资源使用情况，发现有个ksoftirp_CPU0进程的CPU占用率为90%以上。
    一开始认为可能是CPU的主频设置有问题，但客户一口咬定没有问题，客户说CPU主频有240M，我在系统proc文件系统下看到了关于CPU的BogoMIPS为199.98，而且CPU发热很厉害，这样看来主频这边应该没有问题。
    最后回到公司的驱动上，发现公司的驱动使用了几个与软件中断有关的tasklet。加上些调试信息后，发现网卡工作过程似乎都正常，可以正常关联到AP，网卡好像都在处理802.11的管理帧，我将处理的Beacon帧的函数MARK后，那个软中断进程只有51%左右，看来这个中断进程大部分占用率大部分是驱动使用的专门接收管理帧的tasklet所致。
    相关资料也认为，如果CPU的软中断负担太重，会导致这样的现象。但无法解释为什么在其他2.4.20以上的嵌入式平台使用为什么没有会这些问题。
    不懂也没有办法，只能尝试去解决这些问题：今天将那个接收管理帧的tasklet改为任务队列的方式，先在X86下跑一下，一切正常。然后再在客户平台跑一下，哈哈，没有问题。
    但网卡可以关联上AP，但还是PING不通。看来还有其他问题...

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/35548/showart_279476.html