David S. Miller a écrit : On Thu, 17 Mar 2005 20:52:44 +0100 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: - Move the spinlocks out of tr_hash_table[] to a fixed size table : Saves a lot of memory (par
Did you check for performance changes too? From what I understand we can add new lookup and cache miss in the fast packet path. IMO we should be careful with adding new complexity the route hash. Al
Robert Olsson a écrit : Did you check for performance changes too? From what I understand we can add new lookup and cache miss in the fast packet path. Performance is better because in case of stre
Would like to see absolute numbers for UP/SMP single flow and DoS to be confident. I don't think you can depend on timer for GC solely. Timer tick is eternity for todays packet rates. You can distrib
Right. Even for NR_CPUS, I think the table should be dynamically allocated. It is a goal to eliminate all of these huge arrays in the static kernel image, which has grown incredibly too much in recen
David S. Miller a écrit : On Fri, 01 Apr 2005 16:39:48 +0200 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: Maybe I should make a static sizing, (replace the 256 constant by something based on MAX_CPUS
In the former case the kernel image the bootloader has to load is smaller. That's important, believe it or not. It means less TLB entries need to be locked permanently into the MMU on certain platfor
David S. Miller a écrit : On Fri, 01 Apr 2005 23:05:37 +0200 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: You mean you prefer : static spinlock_t *rt_hash_lock ; /* rt_hash_lock = alloc_memory_at_boot
David S. Miller a écrit : On Fri, 01 Apr 2005 23:43:38 +0200 Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: Are you OK if I also use alloc_large_system_hash() to allocate rt_hash_table, instead of the c
Looks fine to me. I'd like to see some feedback from folks like Robert Olsson and co. before applying this, so let's allow the patch to simmer over the weekend, ok? :-)
This patch is doing too many things. How about splitting it up? For instance the spin lock stuff is pretty straightforward and should be in its own patch. The benefits of the GC changes are not obvio
Herbert Xu a écrit : Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote: OK this patch includes everything... - Locking abstraction - rt_check_expire() fixes - New gc_interval_ms sysctl to be able to have ti
Yes a good idea so it can be tested separatly.... Agree with Herbert... Yes thats a pretty much load. Very short flows some reason? What's your ip_rt_gc_min_interval? GC should be allowed to run freq
Robert Olsson a écrit : Eric Dumazet writes: Yes thats a pretty much load. Very short flows some reason? Well... yes. This is a real server, not a DOS simulation. 1 million TCP flows, and about 3 m
I see. OK! Not so bad. Most of your GC likely happens in rt_intern_hash chain pruning. This way you keep hash-chains short and get "datadriven" GC. But there must be bugs causing the crash... Maybe t
Incidentally we should change the way the rehashing is triggered. Instead of doing it regularly, we can do it when we notice that a specific hash chain grows beyond a certain size. The idea is that i
Yes, the secret_interval is way too short. It is a very paranoid default value selected when initially fixing that DoS. I think we should, in the short term, increase the secret interval where it exi
We could also move rt_cache_flush into a kernel thread. When the number of chains is large this function is really expensive for a softirq handler. Cheers, -- Visit Openswan at http://www.openswan.or