Re: [PATCH 2/7] atm: replace del_timer by del_timer_sync
> > It seems this timer rearms itself, so this patch wont be enough I fear. > > > Does that matter? It seems del_timer_sync() may be intended to work despite this (i.e. timer will not fire after call to this function). My earlier attempt to fix a similar issue in sch_red.c resulted in this explanation. http://www.spinics.net/lists/netdev/msg256410.html Vijay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] atm: replace del_timer by del_timer_sync
It seems this timer rearms itself, so this patch wont be enough I fear. Does that matter? It seems del_timer_sync() may be intended to work despite this (i.e. timer will not fire after call to this function). My earlier attempt to fix a similar issue in sch_red.c resulted in this explanation. http://www.spinics.net/lists/netdev/msg256410.html Vijay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Doubts about listen backlog and tcp_max_syn_backlog
> +{ "ListenDrops", N_("%u SYNs to LISTEN sockets dropped"), opt_number },
>
> (see the file debian/patches/CVS-20081003-statistics.c_sync.patch
> in the net-tools src)
>
> i.e., the netstat pkg is printing the value of the TCPEXT MIB counter
> that's counting TCPExtListenDrops.
>
> Theoretically, that number should be the same as that printed by nstat,
> as they are getting it from the same kernel stats counter. I have not
> looked at nstat code (I actually almost always dump the counters from
> /proc/net/{netstat + snmp} via a simple prettyprint script (will send
> you that offline).
>
nstat pretty much does what you describe which is to parse the
/proc/net files(s) and
print the contents. This is one advantage of nstat over netstat. When
you add a new MIB, you
do not need to update nstat.
> If the nstat and netstat counters don't match, something is fishy.
> That nstat output is broken.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Doubts about listen backlog and tcp_max_syn_backlog
+{ ListenDrops, N_(%u SYNs to LISTEN sockets dropped), opt_number },
(see the file debian/patches/CVS-20081003-statistics.c_sync.patch
in the net-tools src)
i.e., the netstat pkg is printing the value of the TCPEXT MIB counter
that's counting TCPExtListenDrops.
Theoretically, that number should be the same as that printed by nstat,
as they are getting it from the same kernel stats counter. I have not
looked at nstat code (I actually almost always dump the counters from
/proc/net/{netstat + snmp} via a simple prettyprint script (will send
you that offline).
nstat pretty much does what you describe which is to parse the
/proc/net files(s) and
print the contents. This is one advantage of nstat over netstat. When
you add a new MIB, you
do not need to update nstat.
If the nstat and netstat counters don't match, something is fishy.
That nstat output is broken.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Doubts about listen backlog and tcp_max_syn_backlog
On 23 January 2013 02:47, Leandro Lucarella wrote: > On Tue, Jan 22, 2013 at 02:01:09PM -0800, Rick Jones wrote: >> >>If that is being overflowed, I believe you should be seeing something like: >> >> >> >> 14 SYNs to LISTEN sockets dropped >> >> >> >>in the output of netstat -s on the system on which the server >> >>application is running. >> > >> >What is that value reporting exactly? >> >> Netstat is reporting the ListenDrops and/or ListenOverflows which >> map to LINUX_MIB_LISTENDROPS and LINUX_MIB_LISTENOVERFLOWS. Those >> get incremented in tcp_v4_syn_recv_sock() (and its v6 version etc) >> >>if (sk_acceptq_is_full(sk)) >> goto exit_overflow; >> >> Will increment both overflows and drops, and drops will increment on >> its own in some additional cases. Note that tcp_v4_conn_request() can also drop SYNs directly (start of TWHS) if acceptq is full and more than one young requests are queued up vim +1504 tcp_ipv4.c if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) goto drop; These drops do not seem to be tracked by any MIB variable and so will not show up in netstat (Also, newer nstat is preferred to netstat ). Maybe we need to track these drops too? Vijay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Doubts about listen backlog and tcp_max_syn_backlog
On 23 January 2013 02:47, Leandro Lucarella leandro.lucare...@sociomantic.com wrote: On Tue, Jan 22, 2013 at 02:01:09PM -0800, Rick Jones wrote: If that is being overflowed, I believe you should be seeing something like: 14 SYNs to LISTEN sockets dropped in the output of netstat -s on the system on which the server application is running. What is that value reporting exactly? Netstat is reporting the ListenDrops and/or ListenOverflows which map to LINUX_MIB_LISTENDROPS and LINUX_MIB_LISTENOVERFLOWS. Those get incremented in tcp_v4_syn_recv_sock() (and its v6 version etc) if (sk_acceptq_is_full(sk)) goto exit_overflow; Will increment both overflows and drops, and drops will increment on its own in some additional cases. Note that tcp_v4_conn_request() can also drop SYNs directly (start of TWHS) if acceptq is full and more than one young requests are queued up vim +1504 tcp_ipv4.c if (sk_acceptq_is_full(sk) inet_csk_reqsk_queue_young(sk) 1) goto drop; These drops do not seem to be tracked by any MIB variable and so will not show up in netstat (Also, newer nstat is preferred to netstat ). Maybe we need to track these drops too? Vijay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
