[Click] click optimize efficiency

Mon Dec 7 01:29:28 EST 2009

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