From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev <netdev@vger.kernel.org>,
Soheil Hassas Yeganeh <soheil@google.com>,
Wei Wang <weiwan@google.com>, Shakeel Butt <shakeelb@google.com>,
Neal Cardwell <ncardwell@google.com>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next 6/7] net: keep sk->sk_forward_alloc as small as possible
Date: Fri, 10 Jun 2022 16:00:51 -0700 (PDT) [thread overview]
Message-ID: <3029e92-4720-eb49-77e1-ca6fc0a855f3@linux.intel.com> (raw)
In-Reply-To: <20220609063412.2205738-7-eric.dumazet@gmail.com>
On Wed, 8 Jun 2022, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Currently, tcp_memory_allocated can hit tcp_mem[] limits quite fast.
>
> Each TCP socket can forward allocate up to 2 MB of memory, even after
> flow became less active.
>
> 10,000 sockets can have reserved 20 GB of memory,
> and we have no shrinker in place to reclaim that.
>
> Instead of trying to reclaim the extra allocations in some places,
> just keep sk->sk_forward_alloc values as small as possible.
>
> This should not impact performance too much now we have per-cpu
> reserves: Changes to tcp_memory_allocated should not be too frequent.
>
> For sockets not using SO_RESERVE_MEM:
> - idle sockets (no packets in tx/rx queues) have zero forward alloc.
> - non idle sockets have a forward alloc smaller than one page.
>
> Note:
>
> - Removal of SK_RECLAIM_CHUNK and SK_RECLAIM_THRESHOLD
> is left to MPTCP maintainers as a follow up.
Yes, noted. Will be sure to clean this up.
Thanks Eric.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> include/net/sock.h | 29 ++---------------------------
> net/core/datagram.c | 3 ---
> net/ipv4/tcp.c | 7 -------
> net/ipv4/tcp_input.c | 4 ----
> net/ipv4/tcp_timer.c | 19 ++++---------------
> net/iucv/af_iucv.c | 2 --
> net/mptcp/protocol.c | 2 +-
> net/sctp/sm_statefuns.c | 2 --
> net/sctp/socket.c | 5 -----
> net/sctp/stream_interleave.c | 2 --
> net/sctp/ulpqueue.c | 4 ----
> 11 files changed, 7 insertions(+), 72 deletions(-)
>
--
Mat Martineau
Intel
next prev parent reply other threads:[~2022-06-10 23:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 6:34 [PATCH net-next 0/7] net: reduce tcp_memory_allocated inflation Eric Dumazet
2022-06-09 6:34 ` [PATCH net-next 1/7] Revert "net: set SK_MEM_QUANTUM to 4096" Eric Dumazet
2022-06-09 15:08 ` Shakeel Butt
2022-06-09 6:34 ` [PATCH net-next 2/7] net: remove SK_MEM_QUANTUM and SK_MEM_QUANTUM_SHIFT Eric Dumazet
2022-06-09 15:09 ` Shakeel Butt
2022-06-09 6:34 ` [PATCH net-next 3/7] net: add per_cpu_fw_alloc field to struct proto Eric Dumazet
2022-06-09 15:11 ` Shakeel Butt
2022-06-09 6:34 ` [PATCH net-next 4/7] net: implement per-cpu reserves for memory_allocated Eric Dumazet
2022-06-09 13:33 ` Soheil Hassas Yeganeh
2022-06-09 13:47 ` Eric Dumazet
2022-06-09 13:48 ` Soheil Hassas Yeganeh
2022-06-09 14:46 ` Neal Cardwell
2022-06-09 15:07 ` Shakeel Butt
2022-06-09 15:09 ` Neal Cardwell
2022-06-09 15:43 ` Eric Dumazet
2022-06-09 15:12 ` Shakeel Butt
2022-06-09 6:34 ` [PATCH net-next 5/7] net: fix sk_wmem_schedule() and sk_rmem_schedule() errors Eric Dumazet
2022-06-09 15:18 ` Shakeel Butt
2022-06-09 6:34 ` [PATCH net-next 6/7] net: keep sk->sk_forward_alloc as small as possible Eric Dumazet
2022-06-09 16:38 ` Shakeel Butt
2022-06-10 23:00 ` Mat Martineau [this message]
2022-10-13 13:15 ` K Prateek Nayak
2022-10-13 14:35 ` Eric Dumazet
2022-10-13 15:52 ` Shakeel Butt
2022-10-14 8:32 ` K Prateek Nayak
2022-10-14 8:30 ` K Prateek Nayak
2022-10-15 20:19 ` Eric Dumazet
2022-10-17 4:04 ` K Prateek Nayak
2022-06-09 6:34 ` [PATCH net-next 7/7] net: unexport __sk_mem_{raise|reduce}_allocated Eric Dumazet
2022-06-09 16:38 ` Shakeel Butt
2022-06-09 13:33 ` [PATCH net-next 0/7] net: reduce tcp_memory_allocated inflation Soheil Hassas Yeganeh
2022-06-11 0:10 ` patchwork-bot+netdevbpf
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=3029e92-4720-eb49-77e1-ca6fc0a855f3@linux.intel.com \
--to=mathew.j.martineau@linux.intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=kuba@kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shakeelb@google.com \
--cc=soheil@google.com \
--cc=weiwan@google.com \
/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.