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
| ||
|
Message-ID: <529f97d7-d9b7-2049-0c9d-a8d6a23b430b@bytedance.com> Date: Tue, 30 May 2023 17:58:14 +0800 From: Abel Wu <wuyun.abel@...edance.com> To: Shakeel Butt <shakeelb@...gle.com> Cc: "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org, cgroups@...r.kernel.org Subject: Re: Re: [PATCH v2 3/4] sock: Consider memcg pressure when raising sockmem On 5/30/23 5:12 AM, Shakeel Butt wrote: > > +linux-mm and cgroups > > On Mon, May 29, 2023 at 07:58:45PM +0800, Abel Wu wrote: >> Hi Shakeel, thanks for reviewing! And sorry for replying so late, >> I was on a vocation :) >> >> On 5/25/23 9:22 AM, Shakeel Butt wrote: >>> On Mon, May 22, 2023 at 03:01:21PM +0800, Abel Wu wrote: >>>> For now __sk_mem_raise_allocated() mainly considers global socket >>>> memory pressure and allows to raise if no global pressure observed, >>>> including the sockets whose memcgs are in pressure, which might >>>> result in longer memcg memstall. >>>> >>>> So take net-memcg's pressure into consideration when allocating >>>> socket memory to alleviate long tail latencies. >>>> >>>> Signed-off-by: Abel Wu <wuyun.abel@...edance.com> >>> >>> Hi Abel, >>> >>> Have you seen any real world production issue which is fixed by this >>> patch or is it more of a fix after reading code? >> >> The latter. But we do observe one common case in the production env >> that p2p service, which mainly downloads container images, running >> inside a container with tight memory limit can easily be throttled and >> keep memstalled for a long period of time and sometimes even be OOM- >> killed. This service shows burst usage of TCP memory and I think it >> indeed needs suppressing sockmem allocation if memcg is already under >> pressure. The memcg pressure is usually caused by too many page caches >> and the dirty ones starting to be wrote back to slow backends. So it >> is insane to continuously receive net data to consume more memory. >> > > We actually made an intentional decision to not throttle the incoming > traffic under memory pressure. See 720ca52bcef22 ("net-memcg: avoid > stalls when under memory pressure"). If you think the throttling > behavior is preferred for your application, please propose the patch > separately and we can work on how to enable flexible policy here. Ah I see. Thanks for providing the context. So suppressing the alloc under memcg pressure could further keep senders waiting if SACKed segs get dropped from the OFO queue. > >>> >>> This code is quite subtle and small changes can cause unintended >>> behavior changes. At the moment the tcp memory accounting and memcg >>> accounting is intermingled and I think we should decouple them. >> >> My original intention to post this patchset is to clarify that: >> >> - proto pressure only considers sysctl_mem[] (patch 2) >> - memcg pressure only indicates the pressure inside itself >> - consider both whenever needs allocation or reclaim (patch 1,3) >> >> In this way, the two kinds of pressure maintain purer semantics, and >> socket core can react on both of them properly and consistently. > > Can you please resend you patch series (without patch 3) and Cc to > linux-mm, cgroups list and memcg maintainers as well? Yeah, absolutely. Thanks, Abel
Powered by blists - more mailing lists