All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Muchun Song <songmuchun@bytedance.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	rafael@kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Shakeel Butt <shakeelb@google.com>, Will Deacon <will@kernel.org>,
	Michal Hocko <mhocko@suse.com>, Roman Gushchin <guro@fb.com>,
	Neil Brown <neilb@suse.de>,
	Sami Tolvanen <samitolvanen@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Feng Tang <feng.tang@intel.com>, Paolo Abeni <pabeni@redhat.com>,
	Willem de Bruijn <willemb@google.com>,
	Florian Westphal <fw@strlen.de>,
	gustavoars@kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,
	Dexuan Cui <decui@microsoft.com>,
	Jakub Sitnicki <jakub@cloudflare.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	dave@stgolabs.net, Michel Lespinasse <walken@google.com>,
	Jann Horn <jannh@google.com>,
	chenqiwu@xiaomi.com, christophe.leroy@c-s.fr,
	Minchan Kim <minchan@kernel.org>, Martin KaFai Lau <kafai@fb.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Kees Cook <keescook@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo
Date: Wed, 14 Oct 2020 08:34:29 +0300	[thread overview]
Message-ID: <20201014053429.GI4251@kernel.org> (raw)
In-Reply-To: <3aa9ff1a-e04f-517c-5ebb-2c27804c143a@infradead.org>

On Tue, Oct 13, 2020 at 08:21:13AM -0700, Randy Dunlap wrote:
> On 10/13/20 8:12 AM, Mike Rapoport wrote:
> > On Tue, Oct 13, 2020 at 07:43:59AM -0700, Randy Dunlap wrote:
> >> On 10/13/20 1:09 AM, Mike Rapoport wrote:
> >>> On Mon, Oct 12, 2020 at 05:53:01PM +0800, Muchun Song wrote:
> >>>> On Mon, Oct 12, 2020 at 5:24 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>>>>
> >>>>> On 10/12/20 10:39 AM, Muchun Song wrote:
> >>>>>> On Mon, Oct 12, 2020 at 3:42 PM Eric Dumazet <edumazet@google.com> wrote:
> >>>>
> >>>> We are not complaining about TCP using too much memory, but how do
> >>>> we know that TCP uses a lot of memory. When I firstly face this problem,
> >>>> I do not know who uses the 25GB memory and it is not shown in the /proc/meminfo.
> >>>> If we can know the amount memory of the socket buffer via /proc/meminfo, we
> >>>> may not need to spend a lot of time troubleshooting this problem. Not everyone
> >>>> knows that a lot of memory may be used here. But I believe many people
> >>>> should know /proc/meminfo to confirm memory users.
> >>>
> >>> If I undestand correctly, the problem you are trying to solve is to
> >>> simplify troubleshooting of memory usage for people who may not be aware
> >>> that networking stack can be a large memory consumer.
> >>>
> >>> For that a paragraph in 'man 5 proc' maybe a good start:
> >>>
> >>> >From ddbcf38576d1a2b0e36fe25a27350d566759b664 Mon Sep 17 00:00:00 2001
> >>> From: Mike Rapoport <rppt@linux.ibm.com>
> >>> Date: Tue, 13 Oct 2020 11:07:35 +0300
> >>> Subject: [PATCH] proc.5: meminfo: add not anout network stack memory
> >>>  consumption
> >>>
> >>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> >>> ---
> >>>  man5/proc.5 | 8 ++++++++
> >>>  1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/man5/proc.5 b/man5/proc.5
> >>> index ed309380b..8414676f1 100644
> >>> --- a/man5/proc.5
> >>> +++ b/man5/proc.5
> >>> @@ -3478,6 +3478,14 @@ Except as noted below,
> >>>  all of the fields have been present since at least Linux 2.6.0.
> >>>  Some fields are displayed only if the kernel was configured
> >>>  with various options; those dependencies are noted in the list.
> >>> +.IP
> >>> +Note that significant part of memory allocated by the network stack
> >>> +is not accounted in the file.
> >>> +The memory consumption of the network stack can be queried
> >>> +using
> >>> +.IR /proc/net/sockstat
> >>> +or
> >>> +.BR ss (8)
> >>>  .RS
> >>>  .TP
> >>>  .IR MemTotal " %lu"
> >>
> >> Hi Mike,
> >>
> >> Could you tell us what units those values are in?
> >> or is that already explained somewhere else?
> > 
> > It is described a few lines above and anyway, "MemTotal" is a part of
> > the diff context ;-)
> 
> with no units AFAICT.
> 
> But I was unclear. I wasn't referring to /proc/meminfo, but instead
> to /proc/net/sockstat and its units:
> 
> sockets: used 1224
> TCP: inuse 11 orphan 1 tw 1 alloc 26 mem 3
> UDP: inuse 4 mem 2
> UDPLITE: inuse 0
> RAW: inuse 0
> FRAG: inuse 0 memory 0
> 
> E.g., for TCP and UDP, are those socket counts or some unit of memory?
> If units of memory, what unit size?

Ah, these are in 4k pages, AFAIU.
And, as it seems /proc/net/sockstat lacks a description in proc.5 at
all...

> thanks.
> -- 
> ~Randy
> 
> 

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2020-10-14  5:34 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-10 10:38 [PATCH] mm: proc: add Sock to /proc/meminfo Muchun Song
2020-10-10 13:06 ` kernel test robot
2020-10-10 13:27 ` kernel test robot
2020-10-10 16:36 ` Randy Dunlap
2020-10-10 16:36   ` Randy Dunlap
2020-10-11  4:42   ` [External] " Muchun Song
2020-10-11  4:42     ` Muchun Song
2020-10-11 13:52 ` Mike Rapoport
2020-10-11 16:00   ` [External] " Muchun Song
2020-10-11 16:00     ` Muchun Song
2020-10-11 18:39 ` Cong Wang
2020-10-11 18:39   ` Cong Wang
2020-10-11 18:39   ` Cong Wang
2020-10-12  4:22   ` [External] " Muchun Song
2020-10-12  4:22     ` Muchun Song
2020-10-12  7:42     ` Eric Dumazet
2020-10-12  7:42       ` Eric Dumazet
2020-10-12  8:39       ` Muchun Song
2020-10-12  8:39         ` Muchun Song
2020-10-12  9:24         ` Eric Dumazet
2020-10-12  9:24           ` Eric Dumazet
2020-10-12  9:53           ` Muchun Song
2020-10-12  9:53             ` Muchun Song
2020-10-12 22:12             ` Cong Wang
2020-10-12 22:12               ` Cong Wang
2020-10-12 22:12               ` Cong Wang
2020-10-13  3:52               ` Muchun Song
2020-10-13  3:52                 ` Muchun Song
2020-10-13  6:55             ` Eric Dumazet
2020-10-13  6:55               ` Eric Dumazet
2020-10-13  8:09             ` Mike Rapoport
2020-10-13 14:43               ` Randy Dunlap
2020-10-13 14:43                 ` Randy Dunlap
2020-10-13 15:12                 ` Mike Rapoport
2020-10-13 15:21                   ` Randy Dunlap
2020-10-13 15:21                     ` Randy Dunlap
2020-10-14  5:34                     ` Mike Rapoport [this message]
2020-10-13 15:28               ` Muchun Song
2020-10-13 15:28                 ` Muchun Song
2020-10-16 15:38               ` Vlastimil Babka
2020-10-16 15:38                 ` Vlastimil Babka
2020-10-16 20:53                 ` Minchan Kim
2020-10-16 20:53                   ` Minchan Kim
2020-10-19 17:23                   ` Shakeel Butt
2020-10-19 17:23                     ` Shakeel Butt
2020-10-12 21:46     ` Cong Wang
2020-10-12 21:46       ` Cong Wang
2020-10-12 21:46       ` Cong Wang
2020-10-13  3:29       ` Muchun Song
2020-10-13  3:29         ` Muchun Song

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=20201014053429.GI4251@kernel.org \
    --to=rppt@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=chenqiwu@xiaomi.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=daniel@iogearbox.net \
    --cc=dave@stgolabs.net \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=ebiederm@xmission.com \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=feng.tang@intel.com \
    --cc=fw@strlen.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=guro@fb.com \
    --cc=gustavoars@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jakub@cloudflare.com \
    --cc=jannh@google.com \
    --cc=jasowang@redhat.com \
    --cc=kafai@fb.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kuba@kernel.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linmiaohe@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=mst@redhat.com \
    --cc=mtk.manpages@gmail.com \
    --cc=neilb@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=samitolvanen@google.com \
    --cc=shakeelb@google.com \
    --cc=songmuchun@bytedance.com \
    --cc=steffen.klassert@secunet.com \
    --cc=tglx@linutronix.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=walken@google.com \
    --cc=will@kernel.org \
    --cc=willemb@google.com \
    --cc=xiyou.wangcong@gmail.com \
    --cc=yoshfuji@linux-ipv6.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.