[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090218.133959.193699273.davem@davemloft.net>
Date: Wed, 18 Feb 2009 13:39:59 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: mingo@...e.hu
Cc: shemminger@...tta.com, kaber@...sh.net, rick.jones2@...com,
dada1@...mosbay.com, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, tglx@...utronix.de,
gandalf@...g.westbo.se, linux-kernel@...r.kernel.org
Subject: Re: [RFT 2/4] Add mod_timer_noact
From: Ingo Molnar <mingo@...e.hu>
Date: Wed, 18 Feb 2009 12:01:44 +0100
> * David Miller <davem@...emloft.net> wrote:
>
> | Introduce mod_timer_noact() which for example is to replace
> | the calls to del_timer()/add_timer() in
> | __nf_ct_refresh_acct(). It works like mod_timer() but doesn't
> | activate or modify the timeout of an inactive timer which is
> | the behaviour we want in order to be able to use timers as a
> | means of synchronization in nf_conntrack.
>
> It does not mention the overhead to the regular timer interfaces
> at all, nor does it explain the reasons for this change
> adequately.
You (conveniently) skipped this part of his commit message, so
I guess this is the part you didn't read very carefully:
A later patch will modify __nf_ct_refresh_acct() to use
mod_timer_noact() which will then save one spin_lock_irqsave()
/ spin_lock_irqrestore() pair per conntrack timer update. This
will also get rid of the race we currently have without adding
more locking in nf_conntrack.
The whole point is to avoid two spin_lock_irqsave() sequences, thus
taking the timer locks twice.
So Ingo, when you say in response:
Why don't you use?
if (del_timer())
add_timer();
you really look foolish and, in fact, disrespectful to Stephen.
This was my objection to your email, it proved that you didn't
really read his changelog message. He explained perfectly well
what the final goal was of his changes.
And you have this knee-jerk reaction quite often.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists