netdev - Re: [PATCH] tcp: Add memory pressure flag to 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] [day] [month] [year] [list]

Message-ID: <CAAvyFNgzqQgG7BEMd69h572ORtVqg_TuSND44sH20F6VTAk9tQ@mail.gmail.com>
Date: Mon, 17 Jul 2023 09:23:36 +1000
From: Jamie Bainbridge <jamie.bainbridge@...il.com>
To: Jay Vosburgh <jay.vosburgh@...onical.com>
Cc: "David S. Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tcp: Add memory pressure flag to sockstat

On Sat, 15 Jul 2023 at 08:45, Jay Vosburgh <jay.vosburgh@...onical.com> wrote:
>
> Jamie Bainbridge <jamie.bainbridge@...il.com> wrote:
>
> >When tuning a system it can be helpful to know whether the protocol is
> >in memory pressure state or not. This can be determined by corresponding
> >the number of pages in "net.ipv4.tcp_mem" with the current allocation,
> >but a global variable already tracks this as the source of truth.
> >
> >Expose that variable in sockstat where other protocol memory usage is
> >already reported.
> >
> >Add "pressure" which is 0 in normal state and 1 under pressure:
> >
> > # grep TCP /proc/net/sockstat
> > TCP: inuse 5 orphan 0 tw 0 alloc 7 mem 1 pressure 0
> >
> > # grep TCP /proc/net/sockstat
> > TCP: inuse 5 orphan 0 tw 0 alloc 7 mem 1 pressure 1
>
>         Isn't this already available in /proc/net/protocols?
>
> protocol  size sockets  memory press maxhdr  slab module     cl co di ac io in de sh ss gs se re sp bi br ha uh gp em
> [...]
> UDP       1472      7       6   NI       0   yes  kernel      y  y  y  n  y  y  y  n  y  y  y  y  y  n  n  y  y  y  n
> TCP       2512      5       1   no     320   yes  kernel      y  y  y  y  y  y  y  y  y  y  y  y  y  n  y  y  y  y  y

I was not aware of this, I was only looking for symbol usage of TCP
and not the generic.

This is perfect, thank you very much!

Jamie

> >Tested by writing a large value to global variable tcp_memory_pressure
> >(it usually stores jiffies when memory pressure was entered) and not
> >just by code review or editing example output.
> >
> >Signed-off-by: Jamie Bainbridge <jamie.bainbridge@...il.com>
> >---
> > net/ipv4/proc.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> >diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
> >index eaf1d3113b62f7dc93fdc7b7c4041140ac63bf69..f4c5ced2de49d5c6d7f5d7ccdaa76c89dcf8c932 100644
> >--- a/net/ipv4/proc.c
> >+++ b/net/ipv4/proc.c
> >@@ -51,16 +51,17 @@
> > static int sockstat_seq_show(struct seq_file *seq, void *v)
> > {
> >       struct net *net = seq->private;
> >-      int orphans, sockets;
> >+      int orphans, sockets, tcp_pressure;
> >
> >       orphans = tcp_orphan_count_sum();
> >       sockets = proto_sockets_allocated_sum_positive(&tcp_prot);
> >+      tcp_pressure = READ_ONCE(tcp_memory_pressure) ? 1 : 0;
> >
> >       socket_seq_show(seq);
> >-      seq_printf(seq, "TCP: inuse %d orphan %d tw %d alloc %d mem %ld\n",
> >+      seq_printf(seq, "TCP: inuse %d orphan %d tw %d alloc %d mem %ld pressure %d\n",
> >                  sock_prot_inuse_get(net, &tcp_prot), orphans,
> >                  refcount_read(&net->ipv4.tcp_death_row.tw_refcount) - 1,
> >-                 sockets, proto_memory_allocated(&tcp_prot));
> >+                 sockets, proto_memory_allocated(&tcp_prot), tcp_pressure);
> >       seq_printf(seq, "UDP: inuse %d mem %ld\n",
> >                  sock_prot_inuse_get(net, &udp_prot),
> >                  proto_memory_allocated(&udp_prot));
> >--
> >2.41.0
> >
> >
>
> ---
>         -Jay Vosburgh, jay.vosburgh@...onical.com