IRQ time is likely time spent in interrupt handlers... most likely your drivers (ethernet and wireless) both install interrupt handlers. This is _not_ time spent in click. This is time spent in your drivers.
Softirq time is generally time spent in tasklets, either explicit tasklets used by drivers or by rx_poll functions. Again, this is time spent in your driver, not in click. If you want to choose what to optimize, then you must do what I suggested in the first email, and measure the performance of each part of your system individually. You could replace FromDevice with InfiniteSource and ToDevice with (Counter -> Discard) and see what byte/packet rate click can achieve on its own. You could run InfiniteSource -> Counter -> ToDevice And see how many packets/bytes per second your drivers are capable of sending. Either way, I feel like your measurements indicate that it is not a click performance problem, but in fact a driver performance problem. Good luck, Cliff On Sun, Nov 29, 2009 at 5:01 AM, Yongheng Qi <[email protected]> wrote: > Dear Cliff > > My system use FromDevice get packet from wireless and ethernet driver. you > mean FromDeivce used interrupt is irq but not the softirq? > > I can't distinguish between irq and softirq at driver , FromDevice and > ToDevice. > > 2009/11/29 Cliff Frey <[email protected]> > >> 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 >>> >>> >> > > > -- > Yongheng Qi > > Mobile: +86 1390 119 7481 > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
