56% softirq implies to me that 56% of the time is spent in the packet receive functions in your ethernet or wireless driver.... as click should not be running at softirq context. 15% irq means that 15% of the time is actually in interrupt handlers, again that is likely your wireless and/or ethernet drivers. So I don't think that your performance problem is in kclick itself. Probably you could get 10% better performance if you were able to get rid of many many click elements in your data path... but I really think that you should be looking at your ethernet/wireless drivers instead.
As I said in my earlier email, you need to break down your problem into smaller pieces before you can blame kclick for the performance. You could also enable CONFIG_PROFILE in linux, which could give you insight into how much time your drivers are spending on what lines of code... but it is a fair amount of work. In addition, with some work you can get linux to also profile your kernel modules... for instance: http://lkml.indiana.edu/hypermail/linux/kernel/0405.1/1115.html Good luck. Cliff On Sat, Nov 28, 2009 at 12:50 AM, Yongheng Qi <[email protected]> wrote: > I tested the NotifierQueue, the instance is the same as before. > > anyone have ideas? Thanks. > > This is the top result: > > Mem: 20540K used, 106700K free, 0K shrd, 0K buff, 6656K cached > CPU: 0% usr 27% sys 0% nice 0% idle 0% io 15% irq 56% softirq > Load average: 0.95 0.88 0.50 > PID PPID USER STAT VSZ %MEM %CPU COMMAND > 777 2 root RW 0 0% 99% [kclick] > 807 691 root R 1960 2% 0% top > 682 664 root S 1992 2% 0% /usr/sbin/dropbear -p 22 > 691 682 root S 1972 2% 0% -ash > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
