netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ono, Kumiko" <kumiko@cs.columbia.edu>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: garbage of TCP sock mem in sockstat?
Date: Wed, 02 May 2007 18:03:26 -0400	[thread overview]
Message-ID: <46390AAE.8020304@cs.columbia.edu> (raw)
In-Reply-To: <20070430.003842.26533021.davem@davemloft.net>

Thanks a lot for your response.

However, it is still unclear, since the allocated memory for TCP socket 
buffers, which I saw via sockstat, shows zero when calling send() after 
recv() as shown in the previous email.

Do you mean that it is necessary to hold the receive buffer allocation 
for future packet when calling only recv(), but not necessary when 
calling send() after recv()?

> 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

Regards,
Kumiko

David Miller wrote:
> From: Kumiko Ono <kumiko@cs.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.


      reply	other threads:[~2007-05-02 22:03 UTC|newest]

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

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=46390AAE.8020304@cs.columbia.edu \
    --to=kumiko@cs.columbia.edu \
    --cc=davem@davemloft.net \
    --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).