From: Eric Dumazet <[email protected]>
Date: Sat, 07 Jan 2006 08:53:52 +0100
> I have no problem with this, since the biggest server I have is 4
> way, but are you sure big machines wont suffer from this single
> spinlock ?
It is the main question.
> Also I dont understand what you want to do after this single
> spinlock patch. How is it supposed to help the 'ip route flush
> cache' problem ? In my case, I have about 600.000 dst-entries :
I don't claim to have a solution to this problem currently.
Doing RCU and going through the whole DST GC machinery is overkill for
an active system. So, perhaps a very simple solution will do:
1) On rt_run_flush(), do not rt_free(), instead collect all active
routing cache entries onto a global list, begin a timer to
fire in 10 seconds (or some sysctl configurable amount).
2) When a new routing cache entry is needed, check the global
list appended to in #1 above first, failing that do dst_alloc()
as is done currently.
3) If timer expires, rt_free() any entries in the global list.
The missing trick is how to ensure RCU semantics when reallocating
from the global list.
The idea is that an active system will immediately repopulate itself
with all of these entries just flushed from the table.
RCU really doesn't handle this kind of problem very well. It truly
excels when work is generated by process context work, not interrupt
work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
