netdev - Re: garbage of TCP sock mem in sockstat?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070430.003842.26533021.davem@davemloft.net>
Date:	Mon, 30 Apr 2007 00:38:42 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	kumiko@...columbia.edu
Cc:	netdev@...r.kernel.org
Subject: Re: garbage of TCP sock mem in sockstat?

From: Kumiko Ono <kumiko@...columbia.edu>
Date: Sat, 07 Apr 2007 23:22:36 -0400

> Could anybody tell me why the garbage in the memory for TCP socket 
> buffers remains? Is this a problem on deallocation of socket buffers, or 
> just on sockstat?  Or I'm missing something?

It is not garbage, it is simply holding on to the receive buffer
allocation in anticipation of future packet receives for that
socket.

The values in the global pool, which you saw via sockstat, are
allocated from on a per-socket basis into a per-socket allocation
quota.  Packets attached to that socket have to take from this
quota.

The idea is that once you get a per-socket allocation, you use
that until you need more.  When you release, you keep the
per-socket allocation unless we are under global memory
pressure.

This prevents having to go to allocate from the global pool
too often which is very expensive especially on SMP since
it is a shared datastructure and requires locking.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html