Comando "ss" no pacote iproute; por que tabela de lajes de consulta para soquetes timewait?

Perdoe-me se este não é o melhor fórum para esta pergunta, mas parece mais relevante para o kernel do que para a própria programação.

Estou escrevendo um script que consulta o sistema em busca de portas abertas para que possamos representar graficamente e monitorar as estatísticas. Para isso, estou usando o comando "ss" do pacote iproute. Se você executar ss -s|grep estab, receberá uma saída semelhante a esta:

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

Minha pergunta tem a ver com a variável timewait, que mostra os soquetes calculados no estado TIME_WAIT. Quando tentei descobrir qual número foi referenciado após a barra, tornou-se uma aventura de busca de código-fonte que finalmente me levou a encontrar o seguinte trecho:

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
       );

Devo admitir que minha busca pelo que "slabstat" deveria significar acabou por me levar a aprender sobre os caches de laje e sua interface de relatórios em / proc / slabinfo.

A pergunta: o que o slabtable tem a ver com os cálculos de soquete TIME_WAIT? Não estou conseguindo descobrir por que esse número é relatado, pois toda vez que executo o comando em todos os servidores em que o experimentei, o número sempre foi zero.

Parece que tcp_tw_bucketsé o que é pesquisado, que é uma estrutura removida a partir do Linux 2.6.12

Portanto, o último número provavelmente sempre será 0, a menos que esteja em kernels de 7 anos.

Quanto à consulta de laje, até onde eu sei, é ridiculamente mais rápida que os outros métodos disponíveis.