From patchwork Tue Oct 22 23:37:08 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Weiner X-Patchwork-Id: 11205495 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7F1761390 for ; Tue, 22 Oct 2019 23:37:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4B5F92064B for ; Tue, 22 Oct 2019 23:37:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="sPfa/q/b" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B5F92064B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 444A36B0003; Tue, 22 Oct 2019 19:37:14 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 3F56A6B0006; Tue, 22 Oct 2019 19:37:14 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BC566B0007; Tue, 22 Oct 2019 19:37:14 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 043406B0003 for ; Tue, 22 Oct 2019 19:37:13 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 7B04282499A8 for ; Tue, 22 Oct 2019 23:37:13 +0000 (UTC) X-FDA: 76073033946.05.pigs82_3efa85c7c043e X-Spam-Summary: 20,1.5,0,6a7e7f817511ed18,d41d8cd98f00b204,hannes@cmpxchg.org,:akpm@linux-foundation.org:shakeelb@google.com:mhocko@suse.com::linux-kernel@vger.kernel.org:cgroups@vger.kernel.org:netdev@vger.kernel.org:kernel-team@fb.com,RULES_HIT:41:355:365:379:541:800:960:966:973:988:989:1260:1311:1314:1345:1437:1515:1535:1543:1711:1730:1747:1777:1792:2194:2196:2198:2199:2200:2201:2393:2559:2562:2729:2731:2890:3138:3139:3140:3141:3142:3355:3834:3865:3866:3867:3868:3870:3871:3872:3874:4042:4117:4225:4250:4321:4385:4560:4605:5007:6261:6653:7875:7903:8603:9121:9707:10004:11026:11233:11473:11658:11914:12043:12296:12297:12438:12517:12519:12555:12660:12679:12895:12986:13146:13156:13161:13228:13229:13230:13869:13894:14040:14093:14096:14181:14394:14721:21067:21080:21444:21450:21451:21627:21740:30001:30005:30054,0,RBL:209.85.222.195:@cmpxchg.org:.lbl8.mailshell.net-62.2.0.100 66.100.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL :neutral X-HE-Tag: pigs82_3efa85c7c043e X-Filterd-Recvd-Size: 6290 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Oct 2019 23:37:12 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id e66so18051698qkf.13 for ; Tue, 22 Oct 2019 16:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SxDH2MC3dIvDcpX5lxZ6Q3L+W2CwFb0BSjYPclNc+5s=; b=sPfa/q/byWY2+7Hn+C2BJi79zjdBqk3v2vpzotcKzKWgvz/US699VypLShsR1FE0xn HoSmnl4W1yx0Zg47VhWYFvSxTicaWE5BsQJKzqWGxCS5sqBcpBKu38tBh+a8FL1O5Z0+ 3tl9QFtVs00aX65Mhrj0USlCsm5tksvq0eWdsoCIGZslYTpUs0DkWlf5BXiidjEmyFfm issgcyUzjYqXPY7d9XNi84i8pwmyT+O2TegVTRdypqWP9B/Ez6s+YXxt9mPLHp850Kfr BUlQ0aF4EKpaXoTjtH4a0bxg0KoBU8pZhDHayYemwEEhZZWw74ZaXu38Cqz5THcyfRIm vxkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SxDH2MC3dIvDcpX5lxZ6Q3L+W2CwFb0BSjYPclNc+5s=; b=n58pnPRG0GyM5zaiiGQsCUSl0aeMXAQrqDQJ+rVRKQ2uzs+ven0djtZiEW7ew1oWv1 GJcnLTpteY+QEGfLplBEdQkLND2v1Zg6PMnqAe2OrBlThd00UWsmFHt4Xy4YU4Z9d3fs Mw78+KzBODPtN68s9RcCH8LjXt4uBA6GUlZIvr7Avq1FwXTak7i+QC7bg+SV0kPRBb3N 3dMoG6U7Ys+viHtteCsGCDZnxyR4jbhtJxfG3uTIyFebmM39K6HObT2mbp6mZoqd+dQw r2EM0vNOUmaX+E3sf0QfU5liC4sQkD/59tM4YcpdWLKgpxeaEveZ6puJbiI0wgjUwFVV woTw== X-Gm-Message-State: APjAAAWBvjlxpP73wNIk1C9ijgi5zqceoEAfD5W84NZTCewYglF3v5bQ lQ07xzC7RSwSmcGnAmcVYTc/mA== X-Google-Smtp-Source: APXvYqyGXnv0taqbCbCiK836ll+xYl7pcxtoIWqynv3sh+hDGIqgBnHcejuxoHJWIeEKtwYT3q/BLA== X-Received: by 2002:a37:6212:: with SMTP id w18mr6001419qkb.204.1571787430558; Tue, 22 Oct 2019 16:37:10 -0700 (PDT) Received: from localhost ([2620:10d:c091:500::3:869e]) by smtp.gmail.com with ESMTPSA id r7sm10300827qkf.124.2019.10.22.16.37.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2019 16:37:09 -0700 (PDT) From: Johannes Weiner To: Andrew Morton Cc: Shakeel Butt , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, netdev@vger.kernel.org, kernel-team@fb.com Subject: [PATCH] mm: memcontrol: fix network errors from failing __GFP_ATOMIC charges Date: Tue, 22 Oct 2019 19:37:08 -0400 Message-Id: <20191022233708.365764-1-hannes@cmpxchg.org> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 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: While upgrading from 4.16 to 5.2, we noticed these allocation errors in the log of the new kernel: [ 8642.253395] SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) [ 8642.269170] cache: tw_sock_TCPv6(960:helper-logs), object size: 232, buffer size: 240, default order: 1, min order: 0 [ 8642.293009] node 0: slabs: 5, objs: 170, free: 0 slab_out_of_memory+1 ___slab_alloc+969 __slab_alloc+14 kmem_cache_alloc+346 inet_twsk_alloc+60 tcp_time_wait+46 tcp_fin+206 tcp_data_queue+2034 tcp_rcv_state_process+784 tcp_v6_do_rcv+405 __release_sock+118 tcp_close+385 inet_release+46 __sock_release+55 sock_close+17 __fput+170 task_work_run+127 exit_to_usermode_loop+191 do_syscall_64+212 entry_SYSCALL_64_after_hwframe+68 accompanied by an increase in machines going completely radio silent under memory pressure. One thing that changed since 4.16 is e699e2c6a654 ("net, mm: account sock objects to kmemcg"), which made these slab caches subject to cgroup memory accounting and control. The problem with that is that cgroups, unlike the page allocator, do not maintain dedicated atomic reserves. As a cgroup's usage hovers at its limit, atomic allocations - such as done during network rx - can fail consistently for extended periods of time. The kernel is not able to operate under these conditions. We don't want to revert the culprit patch, because it indeed tracks a potentially substantial amount of memory used by a cgroup. We also don't want to implement dedicated atomic reserves for cgroups. There is no point in keeping a fixed margin of unused bytes in the cgroup's memory budget to accomodate a consumer that is impossible to predict - we'd be wasting memory and get into configuration headaches, not unlike what we have going with min_free_kbytes. We do this for physical mem because we have to, but cgroups are an accounting game. Instead, account these privileged allocations to the cgroup, but let them bypass the configured limit if they have to. This way, we get the benefits of accounting the consumed memory and have it exert pressure on the rest of the cgroup, but like with the page allocator, we shift the burden of reclaimining on behalf of atomic allocations onto the regular allocations that can block. Cc: stable@kernel.org # 4.18+ Fixes: e699e2c6a654 ("net, mm: account sock objects to kmemcg") Signed-off-by: Johannes Weiner Reviewed-by: Shakeel Butt --- mm/memcontrol.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 8090b4c99ac7..c7e3e758c165 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2528,6 +2528,15 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, goto retry; } + /* + * Memcg doesn't have a dedicated reserve for atomic + * allocations. But like the global atomic pool, we need to + * put the burden of reclaim on regular allocation requests + * and let these go through as privileged allocations. + */ + if (gfp_mask & __GFP_ATOMIC) + goto force; + /* * Unlike in global OOM situations, memcg is not in a physical * memory shortage. Allow dying and OOM-killed tasks to