[Click] click optimize efficiency

Yongheng Qi jetever at gmail.com
Mon Dec 7 07:29:30 EST 2009


this is the oprofile result, when I test, the top cpu is 100%:

samples  %        app name                 symbol name
297294   53.8607  vmlinux                  r4k_wait
22324     4.0444  vmlinux                  half_md4_transform
19912     3.6075  ath_hal.ko               ar5416GetPendingInterrupts
18076     3.2748  ath_hal.ko               ar5416SetInterrupts
8409      1.5235  ath_hal.ko               ar5416GetTsf64
7193      1.3032  vmlinux                  do_ade
6897      1.2495  vmlinux                  handle_adel_int
6692      1.2124  ath_hal.ko               ath_hal_reg_write
6608      1.1972  ath_dev.ko               ath_rx_tasklet
6065      1.0988  merakiclick.ko           IPFilter::push(int, Packet*)
5334      0.9664  merakiclick.ko           SR2GatewaySelector::best_
gateway()
5219      0.9455  ath_hal.ko               ar5416ProcTxDesc
4274      0.7743  ath_pci.ko               ath_tx_startraw
3271      0.5926  vmlinux                  __local_bh_enable
2861      0.5183  ath_dev.ko               ath_check_uapsdtriggers
2746      0.4975  ath_hal.ko               ar5416Set11nRateScenario
2594      0.4700  ath_dev.ko               ath_tx_complete_buf
2570      0.4656  vmlinux                  r4k_dma_cache_inv
2553      0.4625  merakiclick.ko           SR2Forwarder::encap(Packet*,
Vector<IPAddress>, int)
2459      0.4455  merakiclick.ko           WifiEncap::simple_action(Packet*)
2392      0.4334  merakiclick.ko           packet_notifier_hook




2009/12/7 Yongheng Qi <jetever at gmail.com>

> Dear everyone:
>
> I don't success use oprofile on my system. but I try enable the linux
> profile: this is the high cpu loading profile info:
>
> root at OpenWrt:/etc# readprofile -m System.map | sort -nr | head -10
>  36396 *unknown*
>  22185 total                                           0.0121
>   5202 __copy_user                                7.4314
>   1847 do_ade                                        2.3559
>   1716 r4k_wait                                   143.0000
>   1590 handle_adel_int                          28.3929
>    799 r4k_dma_cache_wback_inv            4.5398
>    756 __do_softirq                                  3.6346
>    705 do_dsemulret                                3.8315
>    640 ag71xx_poll                                  0.6324
>
> I think the "unknown" is click mode. accordint to before testing, click
> performece no problem. now use cpu more is r4k_wait and handle_adel_int .
>
> I don't know who use it.
>
> 2009/12/1 Yongheng Qi <jetever at gmail.com>
>
> By the way, I used kernel version is 2.6.26.5
>>
>> On 12/1/09, Yongheng Qi <jetever at gmail.com> wrote:
>> > Dear Cliff and friends:
>> >
>> > Today, I test the click efficiency without driver, it's work very well.
>> > your
>> > point is right, thanks.
>> >
>> > but both ethernet and wireless lead to cpu high loading. so I trace the
>> > element ToDevice code:
>> >
>> > ret = _dev->hard_start_xmit(skb1, _dev);
>> >
>> > this line send packet throuth driver. if don't excute this line. the cpu
>> > load is normal. if excute this line,
>> >
>> > only ToDevice(eth0) will have high cpu loading. I test ToDevice(ath0)
>> too,
>> > the issue like ToDevice(eth0) too.
>> >
>> > I don't know click ToDevice use hard_start_xmit. why have the strange
>> > problem? the hard_start_xmit in the kernel is
>> >
>> > diffient with dev_queue_xmit. I guess in the ToDevice use interrupt have
>> > some conflict with kernel.
>> >
>> > how to solve the problem?
>> >
>> > Thanks
>> >
>> >
>> > 2009/11/30 Cliff Frey <cliff at meraki.com>
>> >
>> >> 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
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Yongheng Qi
>> >
>> > Mobile: +86 1390 119 7481
>> >
>>
>> --
>> Sent from my mobile device
>>
>> Yongheng Qi
>>
>> Mobile: +86 1390 119 7481
>>
>
>
>
> --
> Yongheng Qi
>
> Mobile: +86 1390 119 7481
>



-- 
Yongheng Qi

Mobile: +86 1390 119 7481


More information about the click mailing list