Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+repairing\s+rtcache\s+killer\s*$/: 28 ]

Total 28 documents matching your query.

1. [PATCH] repairing rtcache killer (score: 1)
Author: xxxxxx>
Date: Tue, 5 Aug 2003 17:40:42 +0400 (MSD)
Alexey chain length at <=ip_rt_gc_elasticity results in strong growth of diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c -- a/net/ipv4/route.c Tue Aug 5 17:37:41 2003 +++ b/net/ipv4/route.c Tue Aug
/archives/netdev/2003-08/msg00121.html (9,748 bytes)

2. [PATCH] repairing rtcache killer (score: 1)
Author: xxxxxx>
Date: Tue, 5 Aug 2003 19:08:23 +0200
Hello! I'll guess the setting was very much affected by DoS attacs discussion which indicated very different flowlenths compared to our actual measurement for Uppsala University which had 65 pkts per
/archives/netdev/2003-08/msg00127.html (9,338 bytes)

3. Re: [PATCH] repairing rtcache killer (score: 1)
Author: xxxxxx>
Date: Wed, 6 Aug 2003 00:52:24 -0700
Mama mia! This patch exists in 2.4.22-preX too, so full fix becomes more urgent. Yes, I agree, and algorithm can be even not too smart, something like the following. Before scan loop, we compute: in_
/archives/netdev/2003-08/msg00157.html (10,324 bytes)

4. [PATCH] repairing rtcache killer (score: 1)
Author: @xxxxxxxxxxxxx>
Date: Wed, 6 Aug 2003 19:01:47 +0200
Hello! Crap. We are back to the dst cache overflow again even with routing tables loaded. Well test is now on SMP and 2.6.0-test1. Undo the min_score test and give it retry? Or some new RCU stuff dis
/archives/netdev/2003-08/msg00170.html (9,199 bytes)

5. Re: [PATCH] repairing rtcache killer (score: 1)
Author: on@xxxxxxxxxxx>
Date: Wed, 6 Aug 2003 21:14:56 +0400 (MSD)
Have you already forgotten the whole day lost staring to some impossible numbers for number of misses? :-) The only output which you can get from ratio hits/misses is to _increase_ size of cache whe
/archives/netdev/2003-08/msg00171.html (9,164 bytes)

6. Re: [PATCH] repairing rtcache killer (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Wed, 6 Aug 2003 19:23:52 +0200
We get into complex senarios... we risk that not all CPU see "attacks" so they still contribute to the hash chain and spinning. We can run the chain length calculation at interval as alternative. One
/archives/netdev/2003-08/msg00172.html (12,955 bytes)

7. Re: [PATCH] repairing rtcache killer (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Wed, 6 Aug 2003 21:58:09 +0400 (MSD)
No. This patch is not related to RCU problem at all. It just sanitizes craziness of balancing introduced by chain truncation, that's why the subject is different. :-) I think you did not apply patch
/archives/netdev/2003-08/msg00174.html (8,827 bytes)

8. Re: [PATCH] repairing rtcache killer (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Wed, 6 Aug 2003 22:06:45 +0400 (MSD)
It is the system with positive feedback. Reduction of chain length results in increasing amount of misses and so on. Under normal load it has the only stable state, zero chain length and will never
/archives/netdev/2003-08/msg00175.html (9,171 bytes)

9. Re: [PATCH] repairing rtcache killer (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Wed, 6 Aug 2003 20:20:59 +0200
No correct RCU patches are not applied but even before the RCU pathes we didn't see dst cache overflow during DoS if the routing table was fully loaded and we used hash chain limit patch. Cheers. --r
/archives/netdev/2003-08/msg00176.html (8,938 bytes)

10. Re: [PATCH] repairing rtcache killer (score: 1)
Author: on@xxxxxxxxxxx>
Date: Wed, 6 Aug 2003 22:34:51 +0400 (MSD)
Sure. :-) Robert, did not we discover a week ago that the reason of rcu stalls is rt_run_flush() which runs only when routes change? :-) By the way, to refresh your memory, months ago there was anot
/archives/netdev/2003-08/msg00177.html (8,675 bytes)

11. Re: [PATCH] repairing rtcache killer (score: 1)
Author: t@xxxxxxxxxxxxx
Date: Wed, 6 Aug 2003 20:50:28 +0200
Well is was not the intention to find any optimum or equilibrium point the idea was just to get a different and more agressive setting pure DoS attacks to start with. Something like: if (in_hit < in_
/archives/netdev/2003-08/msg00178.html (9,487 bytes)

12. Re: [PATCH] repairing rtcache killer (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Wed, 6 Aug 2003 23:01:13 +0400 (MSD)
It is _much_ cleaner. Well, it is wrong before all. With default settings for number of flows at pktgen you will get always 1 not depending on length of flow at all. No hits just because cache is to
/archives/netdev/2003-08/msg00180.html (8,833 bytes)

13. Re: [PATCH] repairing rtcache killer (score: 1)
Author: unlap@xxxxxxxx>
Date: Thu, 7 Aug 2003 01:23:18 +0400 (MSD)
I exaggerated saying "serious". The emphasize is rather on "interesting". :-) Mistake were not evident, Robert and me spent day and half to figure out what the hell is going on. :-) It shows only at
/archives/netdev/2003-08/msg00183.html (9,953 bytes)

14. Re: [PATCH] repairing rtcache killer (score: 1)
Author: @xxxxxxxxxxxxx>
Date: Thu, 7 Aug 2003 00:57:28 +0200
This solve the "positive" feedback. Actually the code I tested moved from elasticity2=1 to elasticity*2 as well but this seems more reliable. And the measure (forced gc) should not be inhibited by an
/archives/netdev/2003-08/msg00185.html (10,016 bytes)

15. [PATCH] repairing rtcache killer (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Tue, 5 Aug 2003 17:40:42 +0400 (MSD)
Hello! Alexey chain length at <=ip_rt_gc_elasticity results in strong growth of diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c -- a/net/ipv4/route.c Tue Aug 5 17:37:41 2003 +++ b/net/ipv4/route.c Tu
/archives/netdev/2003-08/msg01093.html (9,748 bytes)

16. [PATCH] repairing rtcache killer (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 5 Aug 2003 19:08:23 +0200
Hello! I'll guess the setting was very much affected by DoS attacs discussion which indicated very different flowlenths compared to our actual measurement for Uppsala University which had 65 pkts per
/archives/netdev/2003-08/msg01099.html (9,396 bytes)

17. Re: [PATCH] repairing rtcache killer (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 6 Aug 2003 00:52:24 -0700
Mama mia! This patch exists in 2.4.22-preX too, so full fix becomes more urgent. Yes, I agree, and algorithm can be even not too smart, something like the following. Before scan loop, we compute: in_
/archives/netdev/2003-08/msg01129.html (10,419 bytes)

18. [PATCH] repairing rtcache killer (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 6 Aug 2003 19:01:47 +0200
Hello! Crap. We are back to the dst cache overflow again even with routing tables loaded. Well test is now on SMP and 2.6.0-test1. Undo the min_score test and give it retry? Or some new RCU stuff dis
/archives/netdev/2003-08/msg01142.html (9,257 bytes)

19. Re: [PATCH] repairing rtcache killer (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Wed, 6 Aug 2003 21:14:56 +0400 (MSD)
Hello! Have you already forgotten the whole day lost staring to some impossible numbers for number of misses? :-) The only output which you can get from ratio hits/misses is to _increase_ size of cac
/archives/netdev/2003-08/msg01143.html (9,197 bytes)

20. Re: [PATCH] repairing rtcache killer (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 6 Aug 2003 19:23:52 +0200
We get into complex senarios... we risk that not all CPU see "attacks" so they still contribute to the hash chain and spinning. We can run the chain length calculation at interval as alternative. One
/archives/netdev/2003-08/msg01144.html (13,091 bytes)


This search system is powered by Namazu