[Click] click optimize efficiency
Cliff Frey
cliff at meraki.com
Sun Nov 29 15:07:01 EST 2009
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 <jetever at gmail.com> 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 <cliff at meraki.com>
>
>> 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
>>>
>>>
>>
>
>
> --
> Yongheng Qi
>
> Mobile: +86 1390 119 7481
>
More information about the click
mailing list