Comando "ss" en el paquete iproute; ¿Por qué consultar la tabla de losa para sockets de tiempo de espera?

Perdóname si este no es el mejor foro para esta pregunta, pero parece más relevante para el kernel que para la programación misma.

Estoy escribiendo un script que consulta los puertos abiertos del sistema para que podamos graficar y monitorear las estadísticas. Para esto, estoy usando el comando "ss" del paquete iproute. Si ejecuta ss -s|grep estab, recibirá una salida similar a esta:

TCP:   296 (estab 6, closed 238, orphaned 0, synrecv 0, timewait 238/0), ports 0

Mi pregunta tiene que ver con la variable timewait, que muestra los sockets calculados en el estado TIME_WAIT. Cuando traté de averiguar a qué número se hacía referencia después de la barra, se convirtió en una aventura vertiginosa de buscar el código fuente que finalmente me llevó a encontrar el siguiente fragmento:

printf("TCP:   %d (estab %d, closed %d, orphaned %d, synrecv %d, timewait %d/%d), ports %d\n",
       s.tcp_total + slabstat.tcp_syns + s.tcp_tws,
       sn.tcp_estab,
       s.tcp_total - (s.tcp4_hashed+s.tcp6_hashed-s.tcp_tws),
       s.tcp_orphans,
       slabstat.tcp_syns,
       s.tcp_tws, slabstat.tcp_tws,
       slabstat.tcp_ports
       );

Debo admitir que mi búsqueda de lo que se suponía que significaba "slabstat" en última instancia me llevó a aprender sobre los cachés de losas y su interfaz de informes en / proc / slabinfo.

La pregunta: ¿Qué tiene que ver el slabtable con los cálculos de socket TIME_WAIT? No puedo entender por qué se informa este número, ya que cada vez que ejecuto el comando en todos los servidores que lo he probado, el número siempre ha sido cero.

Parece que tcp_tw_bucketses lo que finalmente se sondea, que es una estructura eliminada a partir de Linux 2.6.12

Entonces, el último número probablemente siempre sea 0 a menos que esté en núcleos de 7 años.

En cuanto a la consulta de losa, por lo que puedo decir, es ridículamente más rápido que los otros métodos disponibles.