From: Stephen Hemminger <shemminger@vyatta.com>
To: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: loaded router, excessive getnstimeofday in oprofile
Date: Wed, 27 Aug 2008 20:35:18 -0700 [thread overview]
Message-ID: <20080827203518.7f6075a0@extreme> (raw)
In-Reply-To: <200808220457.40892.denys@visp.net.lb>
On Fri, 22 Aug 2008 04:57:40 +0300
Denys Fedoryshchenko <denys@visp.net.lb> wrote:
> I have loaded router (~650 Mbps In+Out), based on 2xAMD Opteron 248, Sun Fire
> X4100. HPET timer available (TSC seems not available on this platform).
> Network interfaces is onboard, connected over PCI-X.
>
> Right now i am using only one processor, cause using only one interface and
> interrupts stick to it. Other is almost not used.
> At peak time i notice in mpstat, that this processor is almost "dead", and if
> i run minor application consuming resources - ping over this router will be
> terrible. For me it is clear - system overloaded. I did oprofile, and here is
> result (at low load time, but at peak time it is very similar).
>
> CPU: AMD64 processors, speed 2193.74 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
> mask of 0x00 (No unit mask) count 100000
> CPU_CLK_UNHALT...|
> samples| %|
> ------------------
> 2679376 71.9851 vmlinux
> 287212 7.7163 e1000
> 278674 7.4870 ip_tables
> 259923 6.9832 nf_conntrack
> 29699 0.7979 iptable_nat
> 26752 0.7187 nf_nat
> 26093 0.7010 nf_conntrack_ipv4
> 16525 0.4440 iptable_mangle
> 14988 0.4027 oprofiled
>
>
> CPU: AMD64 processors, speed 2193.74 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
> mask of 0x00 (No unit mask) count 100000
> samples % symbol name
> 1031727 37.1736 getnstimeofday
> 230457 8.3035 __napi_schedule
> 122154 4.4013 __do_softirq
> 110036 3.9647 dev_queue_xmit
> 88800 3.1995 net_rx_action
> 71163 2.5640 ip_route_input
> 52232 1.8819 local_bh_enable
> 43804 1.5783 get_next_timer_interrupt
> 43387 1.5633 ip_forward
> 35501 1.2791 nf_iterate
> 35212 1.2687 __slab_alloc
> 34652 1.2485 default_idle
> 32375 1.1665 kfree
> 28127 1.0134 kmem_cache_alloc
>
> What is bothering me, why getnstimeofday called so much? Even i remove HTB
> shaper, it still takes 30-40% of whole vmlinux time. From other
> applications - only zebra is running.
> Any ideas?
What kernel version is this? There was a fix to AF_PACKET about a year ago
to reduce this.
next prev parent reply other threads:[~2008-08-28 3:35 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-22 1:57 loaded router, excessive getnstimeofday in oprofile Denys Fedoryshchenko
2008-08-22 2:23 ` Denys Fedoryshchenko
2008-08-26 9:51 ` Jarek Poplawski
2008-08-26 10:29 ` Denys Fedoryshchenko
2008-08-26 10:47 ` Jarek Poplawski
2008-08-26 10:49 ` Denys Fedoryshchenko
2008-08-26 11:07 ` Jarek Poplawski
2008-08-26 11:15 ` Jarek Poplawski
2008-08-26 11:16 ` Denys Fedoryshchenko
2008-08-26 11:32 ` Jarek Poplawski
2008-08-26 11:32 ` Denys Fedoryshchenko
2008-08-26 20:14 ` Evgeniy Polyakov
2008-08-26 20:44 ` Eric Dumazet
2008-08-26 20:51 ` Evgeniy Polyakov
2008-08-27 12:09 ` Denys Fedoryshchenko
2008-08-27 12:36 ` Evgeniy Polyakov
2008-08-27 14:00 ` Denys Fedoryshchenko
2008-08-27 14:23 ` Evgeniy Polyakov
2008-08-27 12:54 ` Andi Kleen
2008-08-27 16:07 ` Rick Jones
2008-08-27 16:27 ` Andi Kleen
2008-08-27 16:49 ` Rick Jones
2008-08-27 16:56 ` Andi Kleen
2008-08-27 16:57 ` Rick Jones
2008-08-27 17:27 ` Eric Dumazet
2008-08-27 18:32 ` loaded router, excessive getnstimeofday in oprofile\ Andi Kleen
2008-08-27 22:23 ` David Miller
2008-08-27 22:38 ` Andi Kleen
2008-08-27 22:18 ` loaded router, excessive getnstimeofday in oprofile David Miller
2008-08-27 22:39 ` Andi Kleen
2008-08-28 0:45 ` Nick Piggin
2008-08-28 0:48 ` David Miller
2008-08-28 1:07 ` Nick Piggin
2008-08-27 16:17 ` Stephen Hemminger
2008-08-27 17:14 ` Jarek Poplawski
2008-08-27 21:34 ` David Miller
2008-08-28 2:39 ` Jason Uhlenkott
2008-08-28 3:10 ` David Miller
2008-08-28 6:28 ` Joe Malicki
2008-08-28 7:22 ` Andi Kleen
2008-08-28 15:02 ` Denys Fedoryshchenko
2008-08-28 19:01 ` Ilpo Järvinen
2008-08-28 19:31 ` David Miller
2008-08-28 16:48 ` Denys Fedoryshchenko
2008-08-28 16:56 ` Andi Kleen
2008-08-28 18:57 ` Eric Dumazet
2008-08-28 19:25 ` Denys Fedoryshchenko
2008-08-28 19:37 ` Eric Dumazet
2008-08-28 19:55 ` Denys Fedoryshchenko
2008-08-29 15:43 ` Stephen Hemminger
2008-08-28 19:36 ` David Miller
2008-08-28 19:59 ` Denys Fedoryshchenko
2008-08-29 15:21 ` Joe Malicki
2008-08-29 15:30 ` Andi Kleen
2008-08-29 15:43 ` Joe Malicki
2008-08-29 20:43 ` Evgeniy Polyakov
2008-08-28 18:00 ` Rick Jones
2008-08-28 19:42 ` David Miller
2008-08-28 20:29 ` Rick Jones
2008-08-28 20:32 ` David Miller
2008-08-28 20:45 ` Rick Jones
2008-08-28 20:47 ` David Miller
2008-09-01 2:39 ` Valdis.Kletnieks
2008-09-01 3:51 ` David Miller
2008-09-01 4:08 ` Valdis.Kletnieks
2008-09-01 4:10 ` David Miller
2008-09-02 17:04 ` Rick Jones
2008-08-28 3:35 ` Stephen Hemminger [this message]
2008-08-28 8:49 ` Denys Fedoryshchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080827203518.7f6075a0@extreme \
--to=shemminger@vyatta.com \
--cc=denys@visp.net.lb \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).