netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kumiko Ono <kumiko@cs.columbia.edu>
To: netdev@vger.kernel.org
Subject: garbage of TCP sock mem in sockstat?
Date: Sat, 07 Apr 2007 23:22:36 -0400	[thread overview]
Message-ID: <46185FFC.8020104@cs.columbia.edu> (raw)

Hi all,

I tried to find out why some amount of memory remains allocated for TCP 
socket buffers after an application completes to read the buffers.
Although I looked for similar topics in this ML, I couldn't find it.

While a client create hundreds of new TCP connections to a server and 
sends 512 bytes data for each connection at 1000 requests/second, I 
monitored the amount of memory allocated for TCP socket buffers in 
/proc/net/sockstat. At lower sending rate, e.g., 100 requests/second, 
this problem does not happen.

The Linux kernel is 2.6.20.

When a server calls read() for all connections, and not call send() for 
echoing messages, the sockstat shows some garbage remaining as follows:

TCP: inuse 13 orphan 0 tw 0 alloc 19 mem 0
TCP: inuse 1226 orphan 0 tw 0 alloc 1232 mem 3
TCP: inuse 2332 orphan 0 tw 0 alloc 2338 mem 3
TCP: inuse 2441 orphan 0 tw 0 alloc 2447 mem 3
TCP: inuse 3654 orphan 0 tw 0 alloc 3660 mem 6
TCP: inuse 4869 orphan 0 tw 0 alloc 4875 mem 6
TCP: inuse 5012 orphan 0 tw 0 alloc 5018 mem 6
TCP: inuse 5012 orphan 0 tw 0 alloc 5018 mem 6
TCP: inuse 5012 orphan 0 tw 0 alloc 5018 mem 6

Even after a day, the sockstat shows the same value on mem.

On the other hand, when a server calls read() and send() for echoing 
messages for all connections, the sockstat shows that all the socket 
buffers are deallocated after competing echoing as follows:

TCP: inuse 13 orphan 0 tw 0 alloc 19 mem 0
TCP: inuse 1237 orphan 0 tw 0 alloc 1243 mem 0
TCP: inuse 2461 orphan 0 tw 0 alloc 2467 mem 0
TCP: inuse 3688 orphan 0 tw 0 alloc 3694 mem 0
TCP: inuse 4912 orphan 0 tw 0 alloc 4918 mem 268
TCP: inuse 5012 orphan 0 tw 0 alloc 5018 mem 101
TCP: inuse 5012 orphan 0 tw 0 alloc 5018 mem 0

Interestingly, when a server calls send() to send 512 byte data, and 
recv() to receive 512 byte data from clients, the sockstat shows 
similarly to that of the echoing.

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?


Regards,
Kumiko

             reply	other threads:[~2007-04-08  3:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-08  3:22 Kumiko Ono [this message]
2007-04-30  7:38 ` garbage of TCP sock mem in sockstat? David Miller
2007-05-02 22:03   ` Ono, Kumiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46185FFC.8020104@cs.columbia.edu \
    --to=kumiko@cs.columbia.edu \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).