* [PATCH/RFC 1/2] optimization updating timer in connection tracking
@ 2004-09-19 21:34 Pablo Neira
2004-09-20 3:40 ` Patrick McHardy
0 siblings, 1 reply; 4+ messages in thread
From: Pablo Neira @ 2004-09-19 21:34 UTC (permalink / raw)
To: Netfilter Development Mailinglist; +Cc: Patrick McHardy
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
Hi Patrick,
I think that I found something interesting reading kernel/timer.c some
weeks ago, well I would like to know about this idea. The comment above
mod_timer speaks by itself...
* mod_timer(timer, expires) is equivalent to:
*
* del_timer(timer); timer->expires = expires; add_timer(timer);
*
* Note that if there are multiple unserialized concurrent users of the
* same timer, then mod_timer() is the only safe way to modify the timeout,
* since add_timer() cannot modify an already running timer.
*
* The function returns whether it has modified a pending timer or not.
* (ie. mod_timer() of an inactive timer returns 0, mod_timer() of an
* active timer returns 1.)
so I think that you could use mod_timer in 2.6 and remove that
WRITE_LOCK when updating the timer, because it's there to serialize
timer updates and now mod_timer controls this possible situation. I
don't have a smp machine here but this week I'll look for a platform to
test it.
If I'm missing something, please let me know.
regards,
Pablo
[-- Attachment #2: conntrack-update-timer-optimize.patch --]
[-- Type: text/x-patch, Size: 941 bytes --]
diff -u -r1.1.1.2 ip_conntrack_core.c
--- a/net/ipv4/netfilter/ip_conntrack_core.c 4 Sep 2004 17:33:46 -0000 1.1.1.2
+++ b/net/ipv4/netfilter/ip_conntrack_core.c 18 Sep 2004 18:59:07 -0000
@@ -1162,14 +1162,13 @@
ct->timeout.expires = extra_jiffies;
ct_add_counters(ct, ctinfo, skb);
} else {
- WRITE_LOCK(&ip_conntrack_lock);
- /* Need del_timer for race avoidance (may already be dying). */
- if (del_timer(&ct->timeout)) {
- ct->timeout.expires = jiffies + extra_jiffies;
- add_timer(&ct->timeout);
- }
+ /* In 2.6 you can use mod_timer to add some extra jiffies
+ * to an active timer, see kernel/timer.c. Even better, we
+ * don't need to lock the conntrack table because mod_timer
+ * takes care about a possible concurrent update, this
+ * kills a pretty bottleneck ;-) */
+ mod_timer(&ct->timeout, jiffies + extra_jiffies);
ct_add_counters(ct, ctinfo, skb);
- WRITE_UNLOCK(&ip_conntrack_lock);
}
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH/RFC 1/2] optimization updating timer in connection tracking
2004-09-19 21:34 [PATCH/RFC 1/2] optimization updating timer in connection tracking Pablo Neira
@ 2004-09-20 3:40 ` Patrick McHardy
2004-09-20 12:27 ` Pablo Neira
0 siblings, 1 reply; 4+ messages in thread
From: Patrick McHardy @ 2004-09-20 3:40 UTC (permalink / raw)
To: Pablo Neira; +Cc: Netfilter Development Mailinglist
Pablo Neira wrote:
> Hi Patrick,
>
> I think that I found something interesting reading kernel/timer.c some
> weeks ago, well I would like to know about this idea. The comment
> above mod_timer speaks by itself...
>
> * mod_timer(timer, expires) is equivalent to:
> *
> * del_timer(timer); timer->expires = expires; add_timer(timer);
> *
> * Note that if there are multiple unserialized concurrent users of the
> * same timer, then mod_timer() is the only safe way to modify the
> timeout,
> * since add_timer() cannot modify an already running timer.
> *
> * The function returns whether it has modified a pending timer or not.
> * (ie. mod_timer() of an inactive timer returns 0, mod_timer() of an
> * active timer returns 1.)
>
> so I think that you could use mod_timer in 2.6 and remove that
> WRITE_LOCK when updating the timer, because it's there to serialize
> timer updates and now mod_timer controls this possible situation. I
> don't have a smp machine here but this week I'll look for a platform
> to test it.
>
> If I'm missing something, please let me know.
We can't use mod_timer because it will re-add a timer that
already went off and dropped it's reference count to the conntrack.
mod_timer is equivalent to del_timer(); add_timer(); but we do
del_timer() && add_timer();
Regards
Patrick
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH/RFC 1/2] optimization updating timer in connection tracking
2004-09-20 3:40 ` Patrick McHardy
@ 2004-09-20 12:27 ` Pablo Neira
2004-09-20 12:56 ` Patrick McHardy
0 siblings, 1 reply; 4+ messages in thread
From: Pablo Neira @ 2004-09-20 12:27 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist
Patrick McHardy escribió:
> We can't use mod_timer because it will re-add a timer that
> already went off and dropped it's reference count to the conntrack.
> mod_timer is equivalent to del_timer(); add_timer(); but we do
> del_timer() && add_timer();
thanks for the hint, in that case, is it worthy adding something like
----- from kernel/timer.c ----
261 /*
262 * This is a common optimization triggered by the
263 * networking code - if the timer is re-modified
264 * to be the same thing then just return:
265 */
266 if (timer->expires == expires && timer_pending(timer))
267 return 1;
----- end -------
inside the write_lock section?
regards,
Pablo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH/RFC 1/2] optimization updating timer in connection tracking
2004-09-20 12:27 ` Pablo Neira
@ 2004-09-20 12:56 ` Patrick McHardy
0 siblings, 0 replies; 4+ messages in thread
From: Patrick McHardy @ 2004-09-20 12:56 UTC (permalink / raw)
To: Pablo Neira; +Cc: Netfilter Development Mailinglist
Pablo Neira wrote:
> Patrick McHardy escribió:
>
>> We can't use mod_timer because it will re-add a timer that
>> already went off and dropped it's reference count to the conntrack.
>> mod_timer is equivalent to del_timer(); add_timer(); but we do
>> del_timer() && add_timer();
>
>
>
> thanks for the hint, in that case, is it worthy adding something like
>
> ----- from kernel/timer.c ----
> 261 /*
> 262 * This is a common optimization triggered by the
> 263 * networking code - if the timer is re-modified
> 264 * to be the same thing then just return:
> 265 */
> 266 if (timer->expires == expires && timer_pending(timer))
> 267 return 1;
> ----- end -------
>
> inside the write_lock section?
We already have something better in old pom:
netfilter/patch-o-matic/optimizations/ip_ct_refresh_optimization.patch:
--- linux-2.4.19-pre9/net/ipv4/netfilter/ip_conntrack_core.c.orig
Mon Jun 3 20:32:28 2002
+++ linux-2.4.19-pre9/net/ipv4/netfilter/ip_conntrack_core.c Mon Jun
3 20:48:13 2002
@@ -1091,8 +1091,10 @@
if (!is_confirmed(ct))
ct->timeout.expires = extra_jiffies;
else {
- /* Need del_timer for race avoidance (may already be
dying). */
- if (del_timer(&ct->timeout)) {
+ /* Don't update timer for each packet, only if it's been >HZ
+ * ticks since last update.
+ * Need del_timer for race avoidance (may already be
dying). */
+ if (abs(jiffies + extra_jiffies - ct->timeout.expires)
>= HZ && del_timer(&ct->timeout)) {
ct->timeout.expires = jiffies + extra_jiffies;
add_timer(&ct->timeout);
}
It is also included in the ctnetlink patch to avoid excessive timeout
notifications.
Regards
Patrick
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-09-20 12:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-19 21:34 [PATCH/RFC 1/2] optimization updating timer in connection tracking Pablo Neira
2004-09-20 3:40 ` Patrick McHardy
2004-09-20 12:27 ` Pablo Neira
2004-09-20 12:56 ` Patrick McHardy
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.