[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <473F145B.5090303@cosmosbay.com>
Date: Sat, 17 Nov 2007 17:18:35 +0100
From: Eric Dumazet <dada1@...mosbay.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] IPV4 : Move ip route cache flush (secret_rebuild) from
softirq to workqueue
Herbert Xu a écrit :
> On Sat, Nov 17, 2007 at 09:41:47AM +0000, Eric Dumazet wrote:
>> [PATCH] IPV4 : Move ip route cache flush (secret_rebuild) from softirq to
>> workqueue
>
> Thanks for your work on this Eric! It's very much needed.
Thanks :)
>
>> @@ -667,7 +697,7 @@ void rt_cache_flush(int delay)
>>
>> if (delay <= 0) {
>> spin_unlock_bh(&rt_flush_lock);
>> - rt_run_flush(0);
>> + rt_run_flush(user_mode);
>> return;
>> }
>
> This seems to be the only potentially softirq caller of rt_run_flush.
> However, I just checked the callers of it and most of them seem to
> hold the RTNL which would indicate that they're in process context.
>
> So do you know if you we have any real softirq callers left?
> If we do perhaps we can look at either moving them out or see
> if they can cope with the flush occuring after the call returns.
>
> If not we can get rid of the softirq special case.
>
Unfortunatly we have softirq callers left. But my goal is to move everything
to process context yes. I choose small patches, so that they can be more
easyly reviewed and accepted.
The most common case is triggered by "ip route flush cache"
Since it's arming a 2 second timer (ip_rt_min_delay) . When this
timer is fired (softirq), it is flushing the table.
Then, every calls to rt_cache_flush(-1) are asking the same thing, while
rt_cache_flush(0) are synchronous (immediate flushing unless a flush already
is in flight)
net/decnet/dn_table.c:621: dn_rt_cache_flush(-1);
net/decnet/dn_table.c:625: dn_rt_cache_flush(-1);
net/decnet/dn_table.c:700: dn_rt_cache_flush(-1);
net/decnet/dn_table.c:707: dn_rt_cache_flush(-1);
net/decnet/dn_table.c:876: dn_rt_cache_flush(-1);
net/decnet/dn_rules.c:234: dn_rt_cache_flush(-1);
net/decnet/dn_fib.c:632: dn_rt_cache_flush(0);
net/decnet/dn_fib.c:644: dn_rt_cache_flush(-1);
net/decnet/dn_fib.c:651: dn_rt_cache_flush(-1);
net/decnet/dn_route.c:339:void dn_rt_cache_flush(int delay)
net/ipv4/devinet.c:1344: rt_cache_flush(0);
net/ipv4/devinet.c:1359: rt_cache_flush(0);
net/ipv4/devinet.c:1374: rt_cache_flush(0);
net/ipv4/devinet.c:1387: rt_cache_flush(0);
net/ipv4/fib_frontend.c:126: rt_cache_flush(-1);
net/ipv4/fib_frontend.c:833: rt_cache_flush(0);
net/ipv4/fib_frontend.c:847: rt_cache_flush(-1);
net/ipv4/fib_frontend.c:857: rt_cache_flush(-1);
net/ipv4/fib_frontend.c:888: rt_cache_flush(-1);
net/ipv4/fib_frontend.c:895: rt_cache_flush(0);
net/ipv4/fib_rules.c:274: rt_cache_flush(-1);
net/ipv4/fib_trie.c:1235: rt_cache_flush(-1);
net/ipv4/fib_trie.c:1288: rt_cache_flush(-1);
net/ipv4/fib_trie.c:1654: rt_cache_flush(-1);
net/ipv4/route.c:671:void rt_cache_flush(int delay)
net/ipv4/route.c:2688: rt_cache_flush(0);
net/ipv4/route.c:2700: rt_cache_flush(flush_delay);
net/ipv4/route.c:2720: rt_cache_flush(delay);
net/ipv4/arp.c:1215: rt_cache_flush(0);
net/ipv4/fib_hash.c:459: rt_cache_flush(-1);
net/ipv4/fib_hash.c:526: rt_cache_flush(-1);
net/ipv4/fib_hash.c:608: rt_cache_flush(-1);
-
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