[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221208003136.fxm6msgiswl2xdac@google.com>
Date: Thu, 8 Dec 2022 00:31:36 +0000
From: Shakeel Butt <shakeelb@...gle.com>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Eric Dumazet <edumazet@...gle.com>,
Ivan Babrou <ivan@...udflare.com>,
Linux MM <linux-mm@...ck.org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Michal Hocko <mhocko@...nel.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Muchun Song <songmuchun@...edance.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
David Ahern <dsahern@...nel.org>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, cgroups@...r.kernel.org,
kernel-team <kernel-team@...udflare.com>
Subject: Re: Low TCP throughput due to vmpressure with swap enabled
On Wed, Dec 07, 2022 at 01:53:00PM +0100, Johannes Weiner wrote:
[...]
>
> I don't mind doing that if necessary, but looking at the code I don't
> see why it would be.
>
> The socket code sets protocol memory pressure on allocations that run
> into limits, and clears pressure on allocations that succeed and
> frees. Why shouldn't we do the same thing for memcg?
>
I think you are right. Let's go with whatever you have for now as this
will reduce vmpressure dependency.
However I think there are still open issues that needs to be addressed
in the future:
1. Unlike TCP memory accounting, memcg has to account/charge user
memory, kernel memory and tcp/netmem. So, it might make more sense to
enter the pressure state in try_charge_memcg() function. This means
charging of user memory or kernel memory can also put the memcg under
socket pressure.
2. On RX path, the memcg charge can succeed due to GFP_ATOMIC flag.
Should we reset the pressure state in that case?
3. On uncharge path, unlike network stack, should we unconditionally
reset the socket pressure state?
Shakeel
Powered by blists - more mailing lists