From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2033C25B08 for ; Wed, 17 Aug 2022 17:37:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6AFF76B0073; Wed, 17 Aug 2022 13:37:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65F3D8D0002; Wed, 17 Aug 2022 13:37:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 529108D0001; Wed, 17 Aug 2022 13:37:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 46F2E6B0073 for ; Wed, 17 Aug 2022 13:37:24 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 14CEFABCF0 for ; Wed, 17 Aug 2022 17:37:24 +0000 (UTC) X-FDA: 79809791166.19.BE641D0 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf18.hostedemail.com (Postfix) with ESMTP id A6DE61C0083 for ; Wed, 17 Aug 2022 17:37:23 +0000 (UTC) Received: by mail-pf1-f181.google.com with SMTP id a22so12060258pfg.3 for ; Wed, 17 Aug 2022 10:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=oHpVPbvxrCLs+hDQJtokFiFQV5w1hhX8KPbSuFBFMus=; b=rkXX2+3DhpH5kPN0GuvNmEMmFMRAP3sHQ5WYgRJMM5myi3cBvZ/q4NRNEF46zlU1Y8 HYoLtM0bC6bV4iLJRtxfb3xwC8HfysVffnCg64kw188YZn0qe2H8IXB5kUfhGnNdQovY Unc/T855gSBad+woJ0nWXAwLgEr4SADSozNIaI1T/Qjxrm7glwGhxJalJc6808Pb1Fio zoNIgdU6LaIyKRXJX/GLgVSubRgeBqoW5ma75upr6jzK6HIXYBsM88owEvuHA/ox3nMH 5SRBEVum7KWTxcNgcl4amFHXe2oy6hVJ2ShckQGxQuta/LIJyBBbL2tyv7JO+sWMDmuJ DWYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=oHpVPbvxrCLs+hDQJtokFiFQV5w1hhX8KPbSuFBFMus=; b=ik2oN29E5KlurUHE6RYEFSWCSFwdVHtihkG+Nh1oTeY9xU7AWA9qfm1P/ZNp7/66fT sa3hau46l0IBTUO6GJNAWpAr38PNUul4hxmMHMIqwGJR82cSvM9PHXfXfm95mE6jUr4d aLvivAjfOsK4i/Yq6bbbZSZ8gwJV//uQVOmU4YliTCcgWWpN2fsVHgTIp0mBpED7YSfv JWyH9RKs3sU6zXT1IS+Inov0seIJjY3L2PmdnptDCprcCSyHRRE2Mcv75wOjl3IPNJHF r/AWUXbBCmnIIYXp+PnyF0ZLjFEjQCDtcDZcCYYvZAD6yAalyCku/qtGL1r1Q9q0cQrS Bjxw== X-Gm-Message-State: ACgBeo0EDN5iJ2TVjOsRjkBSIv4OS5/IkyAIz+QOrWLwZZ/wOjVNfV/U 3mURQuBmWwAGdhZdM3xVfxyqPQQmQPOThRaXe0pcUQ== X-Google-Smtp-Source: AA6agR7RM8hrx5k1uS+mUtIXdZYFeE1DilOpajIypSCuyaPr/6V8tDnU7J/6WG+v5atkr8lrNrO/QsL57Rc0ItJv19c= X-Received: by 2002:a63:5f8e:0:b0:429:c286:4ef7 with SMTP id t136-20020a635f8e000000b00429c2864ef7mr4419598pgb.166.1660757842439; Wed, 17 Aug 2022 10:37:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shakeel Butt Date: Wed, 17 Aug 2022 10:37:11 -0700 Message-ID: Subject: Re: UDP rx packet loss in a cgroup with a memory limit To: Johannes Weiner , Eric Dumazet , netdev Cc: =?UTF-8?Q?Gra=C5=BEvydas_Ignotas?= , Wei Wang , Michal Hocko , Roman Gushchin , Linux MM , Cgroups Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660757843; a=rsa-sha256; cv=none; b=uNoOJt0c93Xlwc2ZpUSa5PYl+2dl/gKMIEQUFIwjv5/VYPABmPYiCLJFHzVUMga3mJGcFP cvXszkv6sDAJ0S+TeRt/YYP/JHOSINQqdFv2bvf7OnGY7a/y6ukh+toIwaC0dkAndy0Vu+ fQvSnl/s+Q220Rxg3IsTGOrqzHrafU8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rkXX2+3D; spf=pass (imf18.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660757843; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oHpVPbvxrCLs+hDQJtokFiFQV5w1hhX8KPbSuFBFMus=; b=3Q9GSNrUuO2rA25xQG2QaSo+PqmndQwviy998NOxxhdhHZ+OTZ/hWQpL6BQXeP8GhQ3NTm JFK3WVXAtjQrjwWmAccbJkFT46EEad6usG10s2oBUMzjJ+UbP/KVKSq+V/OYkNv4ABRePk UBCltC5dvZIPuWO5byKwRQbv/NDipCE= Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rkXX2+3D; spf=pass (imf18.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A6DE61C0083 X-Stat-Signature: n4pt5abxz9f3awh1u5ymzorqieydhjx7 X-Rspam-User: X-HE-Tag: 1660757843-179376 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: + Eric and netdev On Wed, Aug 17, 2022 at 10:13 AM Johannes Weiner wrote= : > > On Wed, Aug 17, 2022 at 07:50:13PM +0300, Gra=C5=BEvydas Ignotas wrote: > > On Tue, Aug 16, 2022 at 9:52 PM Gra=C5=BEvydas Ignotas wrote: > > > Basically, when there is git activity in the container with a memory > > > limit, other processes in the same container start to suffer (very) > > > occasional network issues (mostly DNS lookup failures). > > > > ok I've traced this and it's failing in try_charge_memcg(), which > > doesn't seem to be trying too hard because it's called from irq > > context. > > > > Here is the backtrace: > > > > ? fib_validate_source+0xb4/0x100 > > ? ip_route_input_slow+0xa11/0xb70 > > mem_cgroup_charge_skmem+0x4b/0xf0 > > __sk_mem_raise_allocated+0x17f/0x3e0 > > __udp_enqueue_schedule_skb+0x220/0x270 > > udp_queue_rcv_one_skb+0x330/0x5e0 > > udp_unicast_rcv_skb+0x75/0x90 > > __udp4_lib_rcv+0x1ba/0xca0 > > ? ip_rcv_finish_core.constprop.0+0x63/0x490 > > ip_protocol_deliver_rcu+0xd6/0x230 > > ip_local_deliver_finish+0x73/0xa0 > > __netif_receive_skb_one_core+0x8b/0xa0 > > process_backlog+0x8e/0x120 > > __napi_poll+0x2c/0x160 > > net_rx_action+0x2a2/0x360 > > ? rebalance_domains+0xeb/0x3b0 > > __do_softirq+0xeb/0x2eb > > __irq_exit_rcu+0xb9/0x110 > > sysvec_apic_timer_interrupt+0xa2/0xd0 > > > > > > Calling mem_cgroup_print_oom_meminfo() in such a case reveals: > > > > memory: usage 7812476kB, limit 7812500kB, failcnt 775198 > > swap: usage 0kB, limit 0kB, failcnt 0 > > Memory cgroup stats for > > /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podb8f4f0e9= _fb95_4f2d_8443_e6a78f235c9a.slice/docker-9e7cad93b2e0774d49148474989b41fe6= d67a5985d059d08d9d64495f1539a81.scope: > > anon 348016640 > > file 7502163968 > > kernel 146997248 > > kernel_stack 327680 > > pagetables 2224128 > > percpu 0 > > sock 4096 > > vmalloc 0 > > shmem 0 > > zswap 0 > > zswapped 0 > > file_mapped 112041984 > > file_dirty 1181028352 > > file_writeback 2686976 > > swapcached 0 > > anon_thp 44040192 > > file_thp 0 > > shmem_thp 0 > > inactive_anon 350756864 > > active_anon 36864 > > inactive_file 3614003200 > > active_file 3888070656 > > unevictable 0 > > slab_reclaimable 143692600 > > slab_unreclaimable 545120 > > slab 144237720 > > workingset_refault_anon 0 > > workingset_refault_file 2318 > > workingset_activate_anon 0 > > workingset_activate_file 2318 > > workingset_restore_anon 0 > > workingset_restore_file 0 > > workingset_nodereclaim 0 > > pgfault 334152 > > pgmajfault 1238 > > pgrefill 3400 > > pgscan 819608 > > pgsteal 791005 > > pgactivate 949122 > > pgdeactivate 1694 > > pglazyfree 0 > > pglazyfreed 0 > > zswpin 0 > > zswpout 0 > > thp_fault_alloc 709 > > thp_collapse_alloc 0 > > > > So it basically renders UDP inoperable because of disk cache. I hope > > this is not the intended behavior. Naturally booting with > > cgroup.memory=3Dnosocket solves this issue. > > This is most likely a regression caused by this patch: > > commit 4b1327be9fe57443295ae86fe0fcf24a18469e9f > Author: Wei Wang > Date: Tue Aug 17 12:40:03 2021 -0700 > > net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem() > > Add gfp_t mask as an input parameter to mem_cgroup_charge_skmem(), > to give more control to the networking stack and enable it to change > memcg charging behavior. In the future, the networking stack may deci= de > to avoid oom-kills when fallbacks are more appropriate. > > One behavior change in mem_cgroup_charge_skmem() by this patch is to > avoid force charging by default and let the caller decide when and if > force charging is needed through the presence or absence of > __GFP_NOFAIL. > > Signed-off-by: Wei Wang > Reviewed-by: Shakeel Butt > Signed-off-by: David S. Miller > > We never used to fail these allocations. Cgroups don't have a > kswapd-style watermark reclaimer, so the network relied on > force-charging and leaving reclaim to allocations that can block. > Now it seems network packets could just fail indefinitely. > > The changelog is a bit terse given how drastic the behavior change > is. Wei, Shakeel, can you fill in why this was changed? Can we revert > this for the time being? Does reverting the patch fix the issue? However I don't think it will. Please note that we still have the force charging as before this patch. Previously when mem_cgroup_charge_skmem() force charges, it returns false and __sk_mem_raise_allocated takes suppress_allocation code path. Based on some heuristics, it may allow it or it may uncharge and return failure. The given patch has not changed any heuristic. It has only changed when forced charging happens. After the path the initial call mem_cgroup_charge_skmem() can fail and we take suppress_allocation code path and if heuristics allow, we force charge with __GFP_NOFAIL.