[Click] click optimize efficiency

[Cliff Frey]

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 <jetever at gmail.com> 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
>
>