From: Denys Fedoryshchenko <denys@visp.net.lb>
To: netdev@vger.kernel.org, netfilter@vger.kernel.org
Subject: conntrack timers usage
Date: Mon, 13 Oct 2008 01:49:25 +0300 [thread overview]
Message-ID: <200810130149.25635.denys@visp.net.lb> (raw)
The story with excessive timers usage continue.
Here is my results from /proc/timer_stats for 30 seconds (150Mbps traffic)
This is "non-netfilter" related events
Router-Dora ~ # cat /proc/timer_stats |grep -v '__nf'
Timer Stats Version: v0.2
Sample period: 30.002 s
Overflow: 45261 entries
300, 3308 insmod ipmi_init_msghandler (ipmi_timeout)
1032, 1 swapper neigh_table_init_no_netlink
(neigh_periodic_timer)
3, 0 swapper sk_reset_timer (tcp_delack_timer)
298, 1342 vconfig garp_join_timer_arm (garp_join_timer)
1621, 0 swapper qdisc_watchdog_schedule (qdisc_watchdog)
169, 6 ksoftirqd/1 qdisc_watchdog_schedule (qdisc_watchdog)
3, 6 ksoftirqd/1 neigh_add_timer (neigh_timer_handler)
1417, 0 swapper qdisc_watchdog_schedule (qdisc_watchdog)
2, 6 ksoftirqd/1 neigh_add_timer (neigh_timer_handler)
294, 1352 vconfig garp_join_timer_arm (garp_join_timer)
15, 0 swapper e1000_intr (e1000_watchdog)
3, 1 swapper enqueue_task_rt (sched_rt_period_timer)
60, 0 swapper clocksource_register (clocksource_watchdog)
2, 5003 sshd sk_reset_timer (tcp_write_timer)
30D, 1 swapper schedule_delayed_work_on (delayed_work_timer_fn)
30, 1128 insmod queue_delayed_work (delayed_work_timer_fn)
30D, 1 swapper schedule_delayed_work_on (delayed_work_timer_fn)
1, 0 swapper neigh_add_timer (neigh_timer_handler)
1, 0 swapper neigh_add_timer (neigh_timer_handler)
6318 total events, 210.429 events/sec
And here is netfilter usage, looks like ....
I did also sysctl -w net.netfilter.nf_conntrack_acct=0
1, 0 swapper __nf_ct_refresh_acct (death_by_timeout)
1, 0 swapper __nf_ct_refresh_acct (death_by_timeout)
1, 0 swapper __nf_ct_refresh_acct (death_by_timeout)
1, 0 swapper __nf_ct_refresh_acct (death_by_timeout)
1, 0 swapper __nf_ct_refresh_acct (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
1, 0 swapper __nf_conntrack_confirm (death_by_timeout)
....
Router-Dora ~ # cat /proc/timer_stats |grep '__nf'|wc -l
1005
Is it important to do so much calls to timers in conntrack?
Precision on it is not more than 1 second.
next reply other threads:[~2008-10-12 22:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 22:49 Denys Fedoryshchenko [this message]
2008-10-13 13:20 ` conntrack timers usage Patrick McHardy
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=200810130149.25635.denys@visp.net.lb \
--to=denys@visp.net.lb \
--cc=netdev@vger.kernel.org \
--cc=netfilter@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.