Problem with TCP window too large for TCPRCVBUF still present
Hi, Trying to debug a problem with stalling connections I found this thread: http://forum.openvz.org/index.php?t=msg&goto=9018 which describes the exact problems I'm still having with 2.6.18-028.18 Has it been fixed in this version? Or do you still need someone to test this patch? regards, -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
Re: Problem with TCP window too large for TCPRCVBUF still present
On 11 October 2007 21:46:05 Marcin Owsiany wrote: > Hi, > > Trying to debug a problem with stalling connections I found this thread: > http://forum.openvz.org/index.php?t=msg&goto=9018 > which describes the exact problems I'm still having with 2.6.18-028.18 > > Has it been fixed in this version? Or do you still need someone to test > this patch? Yes, this patch still requires testing. > > regards, -- Thank, Vitaliy Gusev
Hi Vitaliy, [ Cc'ing to Kirill, who sent the original patch ] On Tue, Jan 08, 2008 at 11:12:49AM +0300, Vitaliy Gusev wrote: > On 11 October 2007 21:46:05 Marcin Owsiany wrote: > > Trying to debug a problem with stalling connections I found this thread: > > http://forum.openvz.org/index.php?t=msg&goto=9018 > > which describes the exact problems I'm still having with 2.6.18-028.18 > > > > Has it been fixed in this version? Or do you still need someone to test > > this patch? > > Yes, this patch still requires testing. Can I have the patch as an attachment? The forum mangled the formatting and patch refuses to apply it.. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
try this one attached plz. Marcin Owsiany wrote: > Hi Vitaliy, > > [ Cc'ing to Kirill, who sent the original patch ] > > On Tue, Jan 08, 2008 at 11:12:49AM +0300, Vitaliy Gusev wrote: >> On 11 October 2007 21:46:05 Marcin Owsiany wrote: >>> Trying to debug a problem with stalling connections I found this thread: >>> http://forum.openvz.org/index.php?t=msg&goto=9018 >>> which describes the exact problems I'm still having with 2.6.18-028.18 >>> >>> Has it been fixed in this version? Or do you still need someone to test >>> this patch? >> Yes, this patch still requires testing. > > Can I have the patch as an attachment? The forum mangled the formatting > and patch refuses to apply it.. > --- ./diff.ve7777 2008-02-05 11:25:37.000000000 +0300 +++ ./diff 2008-02-05 11:32:56.000000000 +0300 @@ -1,131 +0,0 @@ -diff --git a/include/net/tcp.h b/include/net/tcp.h -index 0ff49a5..7e8f200 100644 ---- a/include/net/tcp.h -+++ b/include/net/tcp.h -@@ -1815,8 +1815,9 @@ static inline int tcp_win_from_space(int -/* Note: caller must be prepared to deal with negative returns */ -static inline int tcp_space(const struct sock *sk) -{ -- return tcp_win_from_space(sk->sk_rcvbuf - -- atomic_read(&sk->sk_rmem_alloc)); -+ int ub_tcp_rcvbuf = (int) sock_bc(sk)->ub_tcp_rcvbuf; -+ return tcp_win_from_space(min(sk->sk_rcvbuf, ub_tcp_rcvbuf) -+ - atomic_read(&sk->sk_rmem_alloc)); -} - -static inline int tcp_full_space(const struct sock *sk) -diff --git a/include/ub/beancounter.h b/include/ub/beancounter.h -index 3d87afa..fc236e8 100644 ---- a/include/ub/beancounter.h -+++ b/include/ub/beancounter.h -@@ -144,6 +144,8 @@ struct sock_private { -unsigned long ubp_rmem_thres; -unsigned long ubp_wmem_pressure; -unsigned long ubp_maxadvmss; -+ /* Total size of all advertised receive windows for all tcp sockets */ -+ unsigned long ubp_rcv_wnd; -unsigned long ubp_rmem_pressure; -#define UB_RMEM_EXPAND 0 -#define UB_RMEM_KEEP 1 -@@ -177,6 +179,7 @@ #define ub_held_pages ppriv.ubp_held_pa -struct sock_private spriv; -#define ub_rmem_thres spriv.ubp_rmem_thres -#define ub_maxadvmss spriv.ubp_maxadvmss -+#define ub_rcv_wnd spriv.ubp_rcv_wnd -#define ub_rmem_pressure spriv.ubp_rmem_pressure -#define ub_wmem_pressure spriv.ubp_wmem_pressure -#define ub_tcp_sk_list spriv.ubp_tcp_socks -diff --git a/include/ub/ub_sk.h b/include/ub/ub_sk.h -index e65c9ed..02d0137 100644 ---- a/include/ub/ub_sk.h -+++ b/include/ub/ub_sk.h -@@ -34,6 +34,8 @@ struct sock_beancounter { -*/ -unsigned long poll_reserv; -unsigned long forw_space; -+ unsigned long ub_tcp_rcvbuf; -+ unsigned long ub_rcv_wnd_old; -/* fields below are protected by bc spinlock */ -unsigned long ub_waitspc; /* space waiting for */ -unsigned long ub_wcharged; -diff --git a/kernel/ub/ub_net.c b/kernel/ub/ub_net.c -index 74d651a..afee710 100644 ---- a/kernel/ub/ub_net.c -+++ b/kernel/ub/ub_net.c -@@ -420,6 +420,7 @@ static int __sock_charge(struct sock *sk - -added_reserv = 0; -added_forw = 0; -+ skbc->ub_rcv_wnd_old = 0; -if (res == UB_NUMTCPSOCK) { -added_reserv = skb_charge_size(MAX_TCP_HEADER + -1500 - sizeof(struct iphdr) - -@@ -439,6 +440,7 @@ static int __sock_charge(struct sock *sk -added_forw = 0; -} -skbc->forw_space = added_forw; -+ skbc->ub_tcp_rcvbuf = added_forw + SK_STREAM_MEM_QUANTUM; -} -spin_unlock_irqrestore(&ub->ub_lock, flags); - -@@ -528,6 +530,7 @@ void ub_sock_uncharge(struct sock *sk) -skbc->ub_wcharged, skbc->ub, skbc->ub->ub_uid); -skbc->poll_reserv = 0; -skbc->forw_space = 0; -+ ub->ub_rcv_wnd -= is_tcp_sock ? tcp_sk(sk)->rcv_wnd : 0; -spin_unlock_irqrestore(&ub->ub_lock, flags); - -uncharge_beancounter_notop(skbc->ub, -@@ -768,6 +771,44 @@ static void ub_sockrcvbuf_uncharge(struc -* UB_TCPRCVBUF -*/ - -+/* - + * UBC TCP window management mechanism. - + * Every socket may consume no more than sock_quantum. - + * sock_quantum depends on space available and ub_parms[UB_NUMTCPSOCK].held. - + */ -+static void ub_sock_tcp_update_rcvbuf(struct user_beancounter *ub, - + struct sock *sk) -+{ -+ unsigned long allowed; -+ unsigned long reserved; -+ unsigned long available; -+ unsigned long sock_quantum; -+ struct tcp_opt *tp = tcp_sk(sk); -+ struct sock_beancounter *skbc; -+ skbc = sock_bc(sk); -+ -+ if( ub->ub_parms[UB_NUMTCPSOCK].limit * ub->ub_maxadvmss - + > ub->ub_parms[UB_TCPRCVBUF].limit) { - + /* this is defenitly shouldn't happend */ - + return; - + } - + allowed = ub->ub_parms[UB_TCPRCVBUF].barrier; - + ub->ub_rcv_wnd += (tp->rcv_wnd - skbc->ub_rcv_wnd_old); - + skbc->ub_rcv_wnd_old = tp->rcv_wnd; - + reserved = ub->ub_parms[UB_TCPRCVBUF].held + ub->ub_rcv_wnd; - + available = (allowed < reserved)? - + 0:allowed - reserved; - + sock_quantum = max(allowed / ub->ub_parms[UB_NUMTCPSOCK].held, - + ub->ub_maxadvmss); - + if ( skbc->ub_tcp_rcvbuf > sock_quantum) { - + skbc->ub_tcp_rcvbuf = sock_quantum; - + } else { - + skbc->ub_tcp_rcvbuf += min(sock_quantum - skbc->ub_tcp_rcvbuf, - + available); - + } - + - +} - + - int ub_sock_tcp_chargerecv(struct sock *sk, struct sk_buff *skb, - enum ub_severity strict) - { - @@ -804,6 +845,7 @@ int ub_sock_tcp_chargerecv(struct sock * - retval = 0; - for (ub = sock_bc(sk)->ub; ub->parent != NULL; ub = ub->parent); - spin_lock_irqsave(&ub->ub_lock, flags); - + ub_sock_tcp_update_rcvbuf(ub, sk); - ub->ub_parms[UB_TCPRCVBUF].held += chargesize; - if (ub->ub_parms[UB_TCPRCVBUF].held > - ub->ub_parms[UB_TCPRCVBUF].barrier && --- ./include/net/tcp.h.ve7777 2007-12-28 18:24:57.000000000 +0300 +++ ./include/net/tcp.h 2008-02-05 11:32:48.000000000 +0300 @@ -971,8 +971,9 @@ static inline int tcp_win_from_space(int /* Note: caller must be prepared to deal with negative returns */ static inline int tcp_space(const struct sock *sk) { - return tcp_win_from_space(sk->sk_rcvbuf - - atomic_read(&sk->sk_rmem_alloc)); + int ub_tcp_rcvbuf = (int) sock_bc(sk)->ub_tcp_rcvbuf; + return tcp_win_from_space(min(sk->sk_rcvbuf, ub_tcp_rcvbuf) + - atomic_read(&sk->sk_rmem_alloc)); } static inline int tcp_full_space(const struct sock *sk) --- ./include/ub/beancounter.h.ve7777 2007-12-28 18:24:56.000000000 +0300 +++ ./include/ub/beancounter.h 2008-02-05 11:32:48.000000000 +0300 @@ -151,6 +151,8 @@ struct sock_private { unsigned long ubp_rmem_thres; unsigned long ubp_wmem_pressure; unsigned long ubp_maxadvmss; + /* Total size of all advertised receive windows for all tcp sockets */ + unsigned long ubp_rcv_wnd; unsigned long ubp_rmem_pressure; int ubp_tw_count; #define UB_RMEM_EXPAND 0 @@ -218,6 +220,7 @@ struct user_beancounter struct sock_private spriv; #define ub_rmem_thres spriv.ubp_rmem_thres #define ub_maxadvmss spriv.ubp_maxadvmss +#define ub_rcv_wnd spriv.ubp_rcv_wnd #define ub_rmem_pressure spriv.ubp_rmem_pressure #define ub_wmem_pressure spriv.ubp_wmem_pressure #define ub_tcp_sk_list spriv.ubp_tcp_socks --- ./include/ub/ub_sk.h.ve7777 2007-12-28 18:24:52.000000000 +0300 +++ ./include/ub/ub_sk.h 2008-02-05 11:32:48.000000000 +0300 @@ -34,6 +34,8 @@ struct sock_beancounter { */ unsigned long poll_reserv; unsigned long forw_space; + unsigned long ub_tcp_rcvbuf; + unsigned long ub_rcv_wnd_old; /* fields below are protected by bc spinlock */ unsigned long ub_waitspc; /* space waiting for */ unsigned long ub_wcharged; --- ./kernel/ub/ub_net.c.ve7777 2007-12-28 18:24:54.000000000 +0300 +++ ./kernel/ub/ub_net.c 2008-02-05 11:32:48.000000000 +0300 @@ -424,6 +424,7 @@ static int __sock_charge(struct sock *sk added_reserv = 0; added_forw = 0; + skbc->ub_rcv_wnd_old = 0; if (res == UB_NUMTCPSOCK) { added_reserv = skb_charge_size(MAX_TCP_HEADER + 1500 - sizeof(struct iphdr) - @@ -443,6 +444,7 @@ static int __sock_charge(struct sock *sk added_forw = 0; } skbc->forw_space = added_forw; + skbc->ub_tcp_rcvbuf = added_forw + SK_STREAM_MEM_QUANTUM; } spin_unlock_irqrestore(&ub->ub_lock, flags); @@ -533,6 +535,7 @@ void ub_sock_uncharge(struct sock *sk) skbc->ub_wcharged, skbc->ub, skbc->ub->ub_uid); skbc->poll_reserv = 0; skbc->forw_space = 0; + ub->ub_rcv_wnd -= is_tcp_sock ? tcp_sk(sk)->rcv_wnd : 0; spin_unlock_irqrestore(&ub->ub_lock, flags); uncharge_beancounter_notop(skbc->ub, @@ -793,6 +796,44 @@ static void ub_sockrcvbuf_uncharge(struc * UB_TCPRCVBUF */ +/* + * UBC TCP window management mechanism. + * Every socket may consume no more than sock_quantum. + * sock_quantum depends on space available and ub_parms[UB_NUMTCPSOCK].held. + */ +static void ub_sock_tcp_update_rcvbuf(struct user_beancounter *ub, + struct sock *sk) +{ + unsigned long allowed; + unsigned long reserved; + unsigned long available; + unsigned long sock_quantum; + struct tcp_opt *tp = tcp_sk(sk); + struct sock_beancounter *skbc; + skbc = sock_bc(sk); + + if( ub->ub_parms[UB_NUMTCPSOCK].limit * ub->ub_maxadvmss + > ub->ub_parms[UB_TCPRCVBUF].limit) { + /* this is defenitly shouldn't happend */ + return; + } + allowed = ub->ub_parms[UB_TCPRCVBUF].barrier; + ub->ub_rcv_wnd += (tp->rcv_wnd - skbc->ub_rcv_wnd_old); + skbc->ub_rcv_wnd_old = tp->rcv_wnd; + reserved = ub->ub_parms[UB_TCPRCVBUF].held + ub->ub_rcv_wnd; + available = (allowed < reserved)? + 0:allowed - reserved; + sock_quantum = max(allowed / ub->ub_parms[UB_NUMTCPSOCK].held, + ub->ub_maxadvmss); + if ( skbc->ub_tcp_rcvbuf > sock_quantum) { + skbc->ub_tcp_rcvbuf = sock_quantum; + } else { + skbc->ub_tcp_rcvbuf += min(sock_quantum - skbc->ub_tcp_rcvbuf, + available); + } + +} + int ub_sock_tcp_chargerecv(struct sock *sk, struct sk_buff *skb, enum ub_severity strict) { @@ -829,6 +870,7 @@ int ub_sock_tcp_chargerecv(struct sock * retval = 0; ub = top_beancounter(sock_bc(sk)->ub); spin_lock_irqsave(&ub->ub_lock, flags); + ub_sock_tcp_update_rcvbuf(ub, sk); ub->ub_parms[UB_TCPRCVBUF].held += chargesize; if (ub->ub_parms[UB_TCPRCVBUF].held > ub->ub_parms[UB_TCPRCVBUF].barrier &&
Hi, Sorry it took so long to try, but that's how life is if you get a working workaround - little incentive to fix things properly :) On Tue, Feb 05, 2008 at 11:32:46AM +0300, Kirill Korotaev wrote: > try this one attached plz. Unfortunately I get an error: | CC kernel/ub/ub_net.o | mm/mmap.c: In function ‘acct_stack_growth’: | mm/mmap.c:1546: warning: label ‘fail_sec’ defined but not used | kernel/ub/ub_net.c: In function ‘ub_sock_tcp_update_rcvbuf’: | kernel/ub/ub_net.c:795: warning: initialization from incompatible pointer type | kernel/ub/ub_net.c:805: error: dereferencing pointer to incomplete type | kernel/ub/ub_net.c:806: error: dereferencing pointer to incomplete type I guess this is because the patch is against a different version. I also had to tweak the patch by hand so it would apply - looks like top_beancounter() was introduced after the version I have. My version is ovz-028.18-deb.patch (i.e. the version which applies to Debian's 2.6.18). Attached is the ub_net.c file as I have it after applying your tcp window patch. Just in case it's obvious for you how to fix it to work with 028.18-deb. regards, -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
On 14 March 2008 19:03:54 Marcin Owsiany wrote: > Hi, > > Sorry it took so long to try, but that's how life is if you get a > working workaround - little incentive to fix things properly :) > > On Tue, Feb 05, 2008 at 11:32:46AM +0300, Kirill Korotaev wrote: > > try this one attached plz. > > Unfortunately I get an error: > > | CC kernel/ub/ub_net.o > | mm/mmap.c: In function ‘acct_stack_growth’: > | mm/mmap.c:1546: warning: label ‘fail_sec’ defined but not used > | kernel/ub/ub_net.c: In function ‘ub_sock_tcp_update_rcvbuf’: > | kernel/ub/ub_net.c:795: warning: initialization from incompatible pointer type > | kernel/ub/ub_net.c:805: error: dereferencing pointer to incomplete type > | kernel/ub/ub_net.c:806: error: dereferencing pointer to incomplete type > > I guess this is because the patch is against a different version. I also had to > tweak the patch by hand so it would apply - looks like top_beancounter() was I am wonder as top_beancounter() was introduced at 2007-05-15. What exactly OpenVZ version do you use? > introduced after the version I have. > > My version is ovz-028.18-deb.patch (i.e. the version which applies to Debian's > 2.6.18). > > Attached is the ub_net.c file as I have it after applying your tcp window > patch. Just in case it's obvious for you how to fix it to work with 028.18-deb. > I didn't get any attachments... > regards, -- Thank, Vitaliy Gusev
On Fri, Mar 14, 2008 at 07:36:18PM +0300, Vitaliy Gusev wrote: > On 14 March 2008 19:03:54 Marcin Owsiany wrote: > > > > Unfortunately I get an error: > > > > | CC kernel/ub/ub_net.o > > | mm/mmap.c: In function ‘acct_stack_growth’: > > | mm/mmap.c:1546: warning: label ‘fail_sec’ defined but not used > > | kernel/ub/ub_net.c: In function ‘ub_sock_tcp_update_rcvbuf’: > > | kernel/ub/ub_net.c:795: warning: initialization from incompatible pointer type > > | kernel/ub/ub_net.c:805: error: dereferencing pointer to incomplete type > > | kernel/ub/ub_net.c:806: error: dereferencing pointer to incomplete type > > > > I guess this is because the patch is against a different version. I also had to > > tweak the patch by hand so it would apply - looks like top_beancounter() was > > I am wonder as top_beancounter() was introduced at 2007-05-15. > What exactly OpenVZ version do you use? It's called diff-ovz-028.18-deb and I took it from the kernel-patch-openvz debian package maintained by Ola Lindqvist. You can have a look at the diff, it's almost the same as the one in upstream directory within http://ftp.de.debian.org/debian/pool/main/k/kernel-patch-openvz/kernel-patch-openvz_028.18.1etch5.tar.gz Almost all timestamps in the diff file are around 2007-03-09 17:52 > > Attached is the ub_net.c file as I have it after applying your tcp window > > patch. Just in case it's obvious for you how to fix it to work with 028.18-deb. > > > > I didn't get any attachments... Sorry, I'm attaching it now. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
On 14 March 2008 22:31:50 Marcin Owsiany wrote: > On Fri, Mar 14, 2008 at 07:36:18PM +0300, Vitaliy Gusev wrote: > > On 14 March 2008 19:03:54 Marcin Owsiany wrote: > > > > > > Unfortunately I get an error: > > > > > > | CC kernel/ub/ub_net.o > > > | mm/mmap.c: In function ‘acct_stack_growth’: > > > | mm/mmap.c:1546: warning: label ‘fail_sec’ defined but not used > > > | kernel/ub/ub_net.c: In function ‘ub_sock_tcp_update_rcvbuf’: > > > | kernel/ub/ub_net.c:795: warning: initialization from incompatible pointer type > > > | kernel/ub/ub_net.c:805: error: dereferencing pointer to incomplete type > > > | kernel/ub/ub_net.c:806: error: dereferencing pointer to incomplete type > > > > > > I guess this is because the patch is against a different version. I also had to > > > tweak the patch by hand so it would apply - looks like top_beancounter() was > > > > I am wonder as top_beancounter() was introduced at 2007-05-15. > > What exactly OpenVZ version do you use? > > It's called diff-ovz-028.18-deb and I took it from the > kernel-patch-openvz debian package maintained by Ola Lindqvist. > You can have a look at the diff, it's almost the same as the one in > upstream directory within > http://ftp.de.debian.org/debian/pool/main/k/kernel-patch-openvz/kernel-patch-openvz_028.18.1etch5.tar.gz Patch kernel-patch-openvz_028.18.1 is too old. This patch conforms with OpenVZ-028stab018.1 version. I see kernel-patch-openvz_028.51.3d2.tar.gz (that conforms with OpenVZ-028stab051.3) in this repository. Can you try to use this openvz_028.51.3 patch? > > Almost all timestamps in the diff file are around 2007-03-09 17:52 > > > > Attached is the ub_net.c file as I have it after applying your tcp window > > > patch. Just in case it's obvious for you how to fix it to work with 028.18-deb. > > > > > > > I didn't get any attachments... > > Sorry, I'm attaching it now. > -- Thank, Vitaliy Gusev
[ Ola, this is about applying the patch in lenny kernel-patch-openvz to the etch's linux-2.6 ] On Sat, Mar 15, 2008 at 03:53:21PM +0300, Vitaliy Gusev wrote: > Patch kernel-patch-openvz_028.18.1 is too old. This patch conforms > with OpenVZ-028stab018.1 version. > > I see kernel-patch-openvz_028.51.3d2.tar.gz (that conforms with OpenVZ-028stab051.3) > in this repository. Can you try to use this openvz_028.51.3 patch? Unfortunately that one does not apply. If I'm reading the .rej file correctly, it's because the following chunk against net/ipv6/exthdrs.c seems to be missing the line which is shown as line 236 in http://git.openvz.org/?p=linux-2.6.18-openvz;a=blame;f=net/ipv6/exthdrs.c;h=38fdd5f4b1c800181b3aea3b47910aadbb1c646e;hb=HEAD I mean: the line "hdr = (struct ipv6_rt_hdr *) skb->h.raw;" is in debian kernel source tree, but the following chunk of the 028.51.3d2 patch does not expect it (there is just an empty line between the switch and preceding block). Ola, any ideas what's going on? Is it supposed to apply at all? | @@ -255,6 +255,20 @@ static int ipv6_rthdr_rcv(struct sk_buff | return -1; | } | | + switch (hdr->type) { | + case IPV6_SRCRT_TYPE_0: | + /* Completely disallow routing header type 0 for now, it can be | + * made conditional at a later point if needed. Even though the | + * code is non functional at the moment, it is left intact to | + * allow backporting Mobile IPv6 later on. */ | + kfree_skb(skb); | + return -1; | + default: | + IP6_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS); | + icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (&hdr->type) - skb->nh.raw); | + return -1; | + } | + | if (ipv6_addr_is_multicast(&skb->nh.ipv6h->daddr) || | skb->pkt_type != PACKET_HOST) { | IP6_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS); -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
Hi Which kernel source version did you use? I have used: linux-source-2.6.18 2.6.18.dfsg.1-18etch1 kernel-patch-openvz 028.51.3d2 That applies fine. Best regards, // Ola On Sat, Mar 15, 2008 at 06:31:08PM +0000, Marcin Owsiany wrote: > [ Ola, this is about applying the patch in lenny kernel-patch-openvz to the etch's linux-2.6 ] > > On Sat, Mar 15, 2008 at 03:53:21PM +0300, Vitaliy Gusev wrote: > > Patch kernel-patch-openvz_028.18.1 is too old. This patch conforms > > with OpenVZ-028stab018.1 version. > > > > I see kernel-patch-openvz_028.51.3d2.tar.gz (that conforms with OpenVZ-028stab051.3) > > in this repository. Can you try to use this openvz_028.51.3 patch? > > Unfortunately that one does not apply. If I'm reading the .rej file > correctly, it's because the following chunk against net/ipv6/exthdrs.c seems to > be missing the line which is shown as line 236 in > http://git.openvz.org/?p=linux-2.6.18-openvz;a=blame;f=net/ipv6/exthdrs.c;h=38fdd5f4b1c800181b3aea3b47910aadbb1c646e;hb=HEAD > > I mean: the line "hdr = (struct ipv6_rt_hdr *) skb->h.raw;" is in debian > kernel source tree, but the following chunk of the 028.51.3d2 patch does > not expect it (there is just an empty line between the switch and preceding > block). > > Ola, any ideas what's going on? Is it supposed to apply at all? > > > | @@ -255,6 +255,20 @@ static int ipv6_rthdr_rcv(struct sk_buff > | return -1; > | } > | > | + switch (hdr->type) { > | + case IPV6_SRCRT_TYPE_0: > | + /* Completely disallow routing header type 0 for now, it can be > | + * made conditional at a later point if needed. Even though the > | + * code is non functional at the moment, it is left intact to > | + * allow backporting Mobile IPv6 later on. */ > | + kfree_skb(skb); > | + return -1; > | + default: > | + IP6_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS); > | + icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (&hdr->type) - skb->nh.raw); > | + return -1; > | + } > | + > | if (ipv6_addr_is_multicast(&skb->nh.ipv6h->daddr) || > | skb->pkt_type != PACKET_HOST) { > | IP6_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS); > > > -- > Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ > GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 > > "Every program in development at MIT expands until it can read mail." > -- Unknown > -- --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ---- / ola@opalsys.net Annebergsslingan 37 \ | opal@debian.org 654 65 KARLSTAD | | http://opalsys.net/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
On Sat, Mar 15, 2008 at 09:36:07PM +0100, Ola Lundqvist wrote: > Which kernel source version did you use? > > I have used: > linux-source-2.6.18 2.6.18.dfsg.1-18etch1 > kernel-patch-openvz 028.51.3d2 > > That applies fine. Right, this is a problem very similar to the one described in http://bugs.debian.org/470962 (i.e. I'm trying to apply it with max fuzz level == 1, which does not work). Now that I at least know what is going on, I'm going to tweak the patch and try the window size patch. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
On Thu, Mar 20, 2008 at 10:20:12AM +0000, Marcin Owsiany wrote: > Now that I at least know what is going on, I'm going to tweak the patch > and try the window size patch. Unfortunately, using the 028.51.3 patch does not help. kernel/ub/ub_net.c: In function ‘ub_sock_tcp_update_rcvbuf’: kernel/ub/ub_net.c:811: warning: initialization from incompatible pointer type kernel/ub/ub_net.c:821: error: dereferencing pointer to incomplete type kernel/ub/ub_net.c:822: error: dereferencing pointer to incomplete type Attaching the ub_net.c file it tried to compile. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
On 20 March 2008 14:56:02 Marcin Owsiany wrote: > On Thu, Mar 20, 2008 at 10:20:12AM +0000, Marcin Owsiany wrote: > > Now that I at least know what is going on, I'm going to tweak the patch > > and try the window size patch. > > Unfortunately, using the 028.51.3 patch does not help. > > kernel/ub/ub_net.c: In function ‘ub_sock_tcp_update_rcvbuf’: > kernel/ub/ub_net.c:811: warning: initialization from incompatible pointer type > kernel/ub/ub_net.c:821: error: dereferencing pointer to incomplete type > kernel/ub/ub_net.c:822: error: dereferencing pointer to incomplete type > > Attaching the ub_net.c file it tried to compile. > Try attached patch again, please. -- Thank, Vitaliy Gusev
On Thu, Mar 20, 2008 at 04:19:19PM +0300, Vitaliy Gusev wrote: > Try attached patch again, please. Changing "struct tcp_opt" to "struct tcp_sock" fixed the compilation issue, thanks. I also noticed you added another call to ub_sock_tcp_update_rcvbuf(), here: > @@ -829,7 +870,9 @@ int ub_sock_tcp_chargerecv(struct sock *sk, struct sk_buff *skb, > retval = 0; > ub = top_beancounter(sock_bc(sk)->ub); > spin_lock_irqsave(&ub->ub_lock, flags); > + ub_sock_tcp_update_rcvbuf(ub, sk); > ub->ub_parms[UB_TCPRCVBUF].held += chargesize; > + ub_sock_tcp_update_rcvbuf(ub, sk); > if (ub->ub_parms[UB_TCPRCVBUF].held > > ub->ub_parms[UB_TCPRCVBUF].barrier && > strict != UB_FORCE) I'm not predenting I understand what it's all about, but just wanted to ask if you really wanted to add this, and it's not just some copy-paste typo. Anyway, switching to the newer openvz patch has changed the kernel ABI, so it will take me a bit more time to sort my package builds and test the new kernel. This email is just to let you know that it built successfully. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
On Thu, Mar 20, 2008 at 04:19:19PM +0300, Vitaliy Gusev wrote: > Try attached patch again, please. When I use a kernel with this patch, I cannot make it deadlock, which is good, but I also am unable to make the TCP window increase to anything more than 960 _bytes_, even in VE0, which is obviously very bad (limits available bandwidh in my test case by about 50%). As the next step I'm going to build a kernel with the 028.53.3 openvz patch, but without the window fix patch, to see where the problem lies. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
On Sat, Mar 22, 2008 at 11:17:20PM +0000, Marcin Owsiany wrote: > As the next step I'm going to build a kernel with the 028.53.3 openvz > patch, but without the window fix patch, to see where the problem lies. I tried this, and window size is correct (i.e. around 11 KB rather than below 1 KB) with the 028.53.3 openvz patch, but without the "window size fix" patch, so the fault must be in the latter. Please let me know if you have a newer version to be tested. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
Hello! On 24 March 2008 18:39:25 Marcin Owsiany wrote: > On Sat, Mar 22, 2008 at 11:17:20PM +0000, Marcin Owsiany wrote: > > As the next step I'm going to build a kernel with the 028.53.3 openvz > > patch, but without the window fix patch, to see where the problem lies. > > I tried this, and window size is correct (i.e. around 11 KB rather than > below 1 KB) with the 028.53.3 openvz patch, but without the "window size > fix" patch, so the fault must be in the latter. Thanks for your testing! Does the original kernel 028.53.3 still have issue with sending ack? I see if VE has too small tcprcvbuf (about 30000) then server retransmit packets to VE. But i can't reproduce a deadlock state. > > Please let me know if you have a newer version to be tested. > -- Thank, Vitaliy Gusev
On Tue, Mar 25, 2008 at 03:33:08PM +0300, Vitaliy Gusev wrote: > Does the original kernel 028.53.3 still have issue with sending ack? I didn't try. > I see if VE has too small tcprcvbuf (about 30000) then server retransmit > packets to VE. But i can't reproduce a deadlock state. Maybe you need a crappy internet connection to be able to reproduce this :) The way I did that recently was: 1) saturate the link (medium-quality 4 Mb ADSL) in both directions from another machine 2) give it a couple of minutes until the transfer rates are steady 3) start downloading a large file in a VE (I'm in UK and used a debian-cd mirror in Australia for that) 4) give it a couple of minutes until the transfer rate is steady (you can observe the current window size in tcpdump - just wait until it stops changing) 5) then stop both transfers on the other machine 6) after some time (10-20 seconds), the testing VE will notice that more bandwidth has become available, and you will notice that the window size will start increasing, to increase the transfer rate 7) for me, at the point the window size has reached about 9KB (it takes just a couple of seconds from the moment the window started increasing), the deadlock occured -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
On 25 March 2008 15:50:46 Marcin Owsiany wrote: > On Tue, Mar 25, 2008 at 03:33:08PM +0300, Vitaliy Gusev wrote: > > Does the original kernel 028.53.3 still have issue with sending ack? > > I didn't try. > > > I see if VE has too small tcprcvbuf (about 30000) then server retransmit > > packets to VE. But i can't reproduce a deadlock state. > > Maybe you need a crappy internet connection to be able to reproduce this > :) > > The way I did that recently was: > 1) saturate the link (medium-quality 4 Mb ADSL) in both directions from > another machine Traffic from other machine to VE (and vise-versa) or from other machine to VE0? Is it TCP or ICMP traffic? > > 2) give it a couple of minutes until the transfer rates are steady > > 3) start downloading a large file in a VE (I'm in UK and used a > debian-cd mirror in Australia for that) > > 4) give it a couple of minutes until the transfer rate is steady (you > can observe the current window size in tcpdump - just wait until it > stops changing) > > 5) then stop both transfers on the other machine > > 6) after some time (10-20 seconds), the testing VE will notice that > more bandwidth has become available, and you will notice that the > window size will start increasing, to increase the transfer rate > > 7) for me, at the point the window size has reached about 9KB (it takes > just a couple of seconds from the moment the window started > increasing), the deadlock occured > -- Thank, Vitaliy Gusev
On Wed, Mar 26, 2008 at 03:13:56PM +0300, Vitaliy Gusev wrote: > > The way I did that recently was: > > 1) saturate the link (medium-quality 4 Mb ADSL) in both directions from > > another machine > > Traffic from other machine to VE (and vise-versa) or from other machine to VE0? [ Box A ]--\ +----<ADSL>-----[ Internet ]------[ cd mirror in australia ] [ Box B ]--/ Box A contains the VE I'm testing the patch in. Box B is another box on the same LAN, using the same ADSL line, which I used to generate the traffic on the internet link in point "1)". > Is it TCP or ICMP traffic? TCP (HTTP download and an scp upload). -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown