netdev - Re: [PATCH net-next 6/7] net: keep sk->sk_forward

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALvZod7hMHkfk+ivUrRHP7ej2Mx7nFQcOSMx00bYq=8qsE=y3w@mail.gmail.com>
Date:   Thu, 9 Jun 2022 09:38:38 -0700
From:   Shakeel Butt <shakeelb@...gle.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        netdev <netdev@...r.kernel.org>,
        Soheil Hassas Yeganeh <soheil@...gle.com>,
        Wei Wang <weiwan@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next 6/7] net: keep sk->sk_forward_alloc as small as possible

On Wed, Jun 8, 2022 at 11:34 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> From: Eric Dumazet <edumazet@...gle.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.
>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

This is a nice cleanup.

Reviewed-by: Shakeel Butt <shakeelb@...gle.com>