From: Cong Wang <xiyou.wangcong@gmail.com> To: Muchun Song <songmuchun@bytedance.com> Cc: 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>, Eric Dumazet <edumazet@google.com>, 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>, shakeelb@google.com, will@kernel.org, Michal Hocko <mhocko@suse.com>, Roman Gushchin <guro@fb.com>, Neil Brown <neilb@suse.de>, rppt@kernel.org, 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>, Randy Dunlap <rdunlap@infradead.org>, Florian Westphal <fw@strlen.de>, gustavoars@kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>, 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, 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> Subject: Re: [PATCH] mm: proc: add Sock to /proc/meminfo Date: Sun, 11 Oct 2020 11:39:02 -0700 [thread overview] Message-ID: <CAM_iQpUQXctR8UBNRP6td9dWTA705tP5fWKj4yZe9gOPTn_8oQ@mail.gmail.com> (raw) In-Reply-To: <20201010103854.66746-1-songmuchun@bytedance.com> On Sat, Oct 10, 2020 at 3:39 AM Muchun Song <songmuchun@bytedance.com> wrote: > > The amount of memory allocated to sockets buffer can become significant. > However, we do not display the amount of memory consumed by sockets > buffer. In this case, knowing where the memory is consumed by the kernel We do it via `ss -m`. Is it not sufficient? And if not, why not adding it there rather than /proc/meminfo? > static inline void __skb_frag_unref(skb_frag_t *frag) > { > - put_page(skb_frag_page(frag)); > + struct page *page = skb_frag_page(frag); > + > + if (put_page_testzero(page)) { > + dec_sock_node_page_state(page); > + __put_page(page); > + } > } You mix socket page frag with skb frag at least, not sure this is exactly what you want, because clearly skb page frags are frequently used by network drivers rather than sockets. Also, which one matches this dec_sock_node_page_state()? Clearly not skb_fill_page_desc() or __skb_frag_ref(). Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Cong Wang <xiyou.wangcong@gmail.com> To: Muchun Song <songmuchun@bytedance.com> Cc: Miaohe Lin <linmiaohe@huawei.com>, Feng Tang <feng.tang@intel.com>, Michal Hocko <mhocko@suse.com>, "Michael S. Tsirkin" <mst@redhat.com>, Neil Brown <neilb@suse.de>, Alexei Starovoitov <ast@kernel.org>, LKML <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, Eric Dumazet <edumazet@google.com>, Christian Brauner <christian.brauner@ubuntu.com>, walken@google.com, will@kernel.org, Steffen Klassert <steffen.klassert@secunet.com>, dave@stgolabs.net, Herbert Xu <herbert@gondor.apana.org.au>, Daniel Borkmann <daniel@iogearbox.net>, rafael@kernel.org, decui@microsoft.com, Peter Zijlstra <peterz@infradead.org>, samitolvanen@google.com, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>, Paolo Abeni <pabeni@redhat.com>, Alexey Dobriyan <adobriyan@gmail.com>, Pablo Neira Ayuso <pablo@netfilter.org>, "Eric W. Biederman" <ebiederm@xmission.com>, Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>, shakeelb@google.com, Jakub Kicinski <kuba@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, virtualization@lists.linux-foundation.org, chenqiwu@xiaomi.com, Martin KaFai Lau <kafai@fb.com>, Jakub Sitnicki <jakub@cloudflare.com>, christophe.leroy@c-s.fr, Willem de Bruijn <willemb@google.com>, Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>, Greg KH <gregkh@linuxfoundation.org>, Randy Dunlap <rdunlap@infradead.org>, Florian Westphal <fw@strlen.de>, gustavoars@kernel.org, Roman Gushchin <guro@fb.com>, Minchan Kim <minchan@kernel.org>, rppt@kernel.org, Linux Kernel Network Developers <netdev@vger.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, David Miller <davem@davemloft.net>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: Re: [PATCH] mm: proc: add Sock to /proc/meminfo Date: Sun, 11 Oct 2020 11:39:02 -0700 [thread overview] Message-ID: <CAM_iQpUQXctR8UBNRP6td9dWTA705tP5fWKj4yZe9gOPTn_8oQ@mail.gmail.com> (raw) In-Reply-To: <20201010103854.66746-1-songmuchun@bytedance.com> On Sat, Oct 10, 2020 at 3:39 AM Muchun Song <songmuchun@bytedance.com> wrote: > > The amount of memory allocated to sockets buffer can become significant. > However, we do not display the amount of memory consumed by sockets > buffer. In this case, knowing where the memory is consumed by the kernel We do it via `ss -m`. Is it not sufficient? And if not, why not adding it there rather than /proc/meminfo? > static inline void __skb_frag_unref(skb_frag_t *frag) > { > - put_page(skb_frag_page(frag)); > + struct page *page = skb_frag_page(frag); > + > + if (put_page_testzero(page)) { > + dec_sock_node_page_state(page); > + __put_page(page); > + } > } You mix socket page frag with skb frag at least, not sure this is exactly what you want, because clearly skb page frags are frequently used by network drivers rather than sockets. Also, which one matches this dec_sock_node_page_state()? Clearly not skb_fill_page_desc() or __skb_frag_ref(). Thanks. _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2020-10-11 18:39 UTC|newest] Thread overview: 51+ 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 [this message] 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 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 2020-10-10 13:57 kernel test robot
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=CAM_iQpUQXctR8UBNRP6td9dWTA705tP5fWKj4yZe9gOPTn_8oQ@mail.gmail.com \ --to=xiyou.wangcong@gmail.com \ --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=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=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=rppt@kernel.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=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: linkBe 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.