From patchwork Fri Sep 1 06:21:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Abel Wu X-Patchwork-Id: 13372079 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 8AE85CA0FEB for ; Fri, 1 Sep 2023 06:24:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29C198D0020; Fri, 1 Sep 2023 02:24:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24CBF8D0002; Fri, 1 Sep 2023 02:24:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13B148D0020; Fri, 1 Sep 2023 02:24:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 043338D0002 for ; Fri, 1 Sep 2023 02:24:28 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C9026C0138 for ; Fri, 1 Sep 2023 06:24:27 +0000 (UTC) X-FDA: 81187039374.01.63984F7 Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by imf08.hostedemail.com (Postfix) with ESMTP id 041C9160006 for ; Fri, 1 Sep 2023 06:24:25 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=VheQXM6t; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf08.hostedemail.com: domain of wuyun.abel@bytedance.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=wuyun.abel@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693549466; a=rsa-sha256; cv=none; b=Tl1Vwc88rPSibT4ShPehHcTGQzTWjmtFTIRQib7U8yJ+L70R9JknxQPTNNwsj+BP0oFM0y Bv8820CPw+LNJSjvOpyi1Pktr7WJwc89EO3iPr+CpX7NljOtcEPZXj68IVSVvVnCH+TLOm 7CAyn7I8sqrYfq1IaHQQEDotcdsQlhI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=VheQXM6t; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf08.hostedemail.com: domain of wuyun.abel@bytedance.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=wuyun.abel@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693549466; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0JmFLfbSmI2emm6GyT4GHqCHxeUZuXTxsBg8j/3SD1Q=; b=Pogc9TDGfbMODSL1s96OHSCgbfAi8DgfozGvbIoNOIY7lhvMEZ6n3j93LMuvHU+9n5j1OS QpUY8U2qgo4LZcjNJn2xMuhsey28dA9sNvZy0p27aAnrEil8IctlIvhjyrA2xRxkl0xUOs 8xw6HxwAPuEpQZrFwNrAP7gHtxlhTSY= Received: by mail-oi1-f177.google.com with SMTP id 5614622812f47-3a7e68f4214so1058962b6e.1 for ; Thu, 31 Aug 2023 23:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1693549465; x=1694154265; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0JmFLfbSmI2emm6GyT4GHqCHxeUZuXTxsBg8j/3SD1Q=; b=VheQXM6tDLWJupwWkDF/f1KwPzAqEluvBL7U9w6/X5ogvqKWr9oiBHYeTHHwqFm8Hu yNI1o+LHgPYo+7S7MwsMFsipDeJsjirv4OGcSATwJ2Zo/yc0j+paESh7XM00oXJYXZj/ 2UABripYY+UYberfRtVdo0hdPCP4pRmU5chRZtdZEBEc7c7scXgtZy3Sk/M/2qMOMyDb ju9IMaENYRaFj5kpiawW49QWjxPz2kL25Rih2Ch9nCL/Upl8yogUt7GR/Kd2fWyUzuoU GzQgC03QtIR8rQ3ZH7K78S3ZOW1yN5QjYghTX50SFCJ4zpfWJSTzhcENWC7Di2VdY8T4 1qdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693549465; x=1694154265; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0JmFLfbSmI2emm6GyT4GHqCHxeUZuXTxsBg8j/3SD1Q=; b=XwrUqPg6KT4O2vcqfbrSeiPBkr6iDuEaAfRI7A+ipMrvNHZluvsnjuRHTNTneHHHPv RtUBxeVz4PgIfxHQVwMPSgCQw7hJ1WyZ+uT35vHD7vLKeVFROWMik9SHapZxRZunKfRW ckDPLUIL2nNncnUdnNKZpTNudgYe9ba98WPxoTZi23sBDMH1/2KCVwVvRVjB1263OUj6 Eo9tP6xvRU4Y3aFgjxPs1RFuPOWkKn6jWGbfYj+CVR1QIHshA4e7m1S0DUBiJPhVUCuQ oCVdeOgvjZN1ZiWwawsy+ozY2jAiTOD2WXx33Pasp64sqcNBOpQKzoiLYpLND6ZPDQ2y vDVg== X-Gm-Message-State: AOJu0YzIEWYMz3pQ/nk6MoL+nu/A3MXz6xDBB44mi0kQFkxelzh6PtB+ 904k3jPIb+hJx6nEETm8rvuAcQ== X-Google-Smtp-Source: AGHT+IFA+ZQPRlE/tLVc4UK8tlm+PIJyTz7163uxOg1QtvjOk/HKCDfhxw5xWkpOivUFycx5AMQukQ== X-Received: by 2002:aca:2b16:0:b0:3a3:eab8:8c40 with SMTP id i22-20020aca2b16000000b003a3eab88c40mr1685121oik.54.1693549465089; Thu, 31 Aug 2023 23:24:25 -0700 (PDT) Received: from C02DV8HUMD6R.bytedance.net ([203.208.167.146]) by smtp.gmail.com with ESMTPSA id fm19-20020a056a002f9300b0068c1ac1784csm2223265pfb.59.2023.08.31.23.24.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Aug 2023 23:24:24 -0700 (PDT) From: Abel Wu To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Andrew Morton , Shakeel Butt , Roman Gushchin , Michal Hocko , Johannes Weiner , Yosry Ahmed , Yu Zhao , "Matthew Wilcox (Oracle)" , Kefeng Wang , Abel Wu , Yafang Shao , Kuniyuki Iwashima , Martin KaFai Lau , Breno Leitao , Alexander Mikhalitsyn , David Howells , Jason Xing Cc: linux-kernel@vger.kernel.org (open list), netdev@vger.kernel.org (open list:NETWORKING [GENERAL]), linux-mm@kvack.org (open list:MEMORY MANAGEMENT) Subject: [RFC PATCH net-next 3/3] sock: Throttle pressure-aware sockets under pressure Date: Fri, 1 Sep 2023 14:21:28 +0800 Message-Id: <20230901062141.51972-4-wuyun.abel@bytedance.com> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20230901062141.51972-1-wuyun.abel@bytedance.com> References: <20230901062141.51972-1-wuyun.abel@bytedance.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 041C9160006 X-Stat-Signature: 8qjdnsj9foh9g787rd1gikkcfiqqk3nd X-HE-Tag: 1693549465-697011 X-HE-Meta: U2FsdGVkX1/qc94Yy23itUw8rOfxMFbYn9dO//tFQU48HXuqnx4kj6U8QJCfokemzrQEgxoZPtKHerZ3I9rfxlkFIOCH2HV3kJwy+lflH/bOVVSRELOlKOZCf98PDW7xnMmgrZ+JI0gn8DMKJ5ZvdS0ogbtAmCkAQrWdSA/9gSV0GSD6F7tFrHXke1AlaZBlfBq4VpSV8WdZSmAl/7tpBPweW5tC+jyUHTy6EDS0yTTfNoJ26cpKSLFs3b8ajHH4Dgr+UPF8fkV/e5SuTcPCg+nIDxSogXGWkcvlrlPEaoyLcppUW5TZBjQ4FOcCc2Uk75mEeWwp5BL+NuMahaT/alUYhqJTlPXY1e3aSPmq4a3UKgbXRgc4wLL0f1G1xiWO7jSDr3vha2feBekKTZHdvTzHD9Iryo84Kbc6cy5EYBePRKA5+CQnyyICykT8ZylqCdJfTiA9YCB/h/W6ciTlDUyy3oDqgBmss80W10XHv1H5aOPr/Nr+7wdi4/zXudytA7Qu97cnbcV0GWrHAP2ey+WFRekGSj6PHAqN+sApHNptRaAO3TyBttAPicvnv12riHXQ2WJv6BzDnU9dulW1ruiiOEicOUEL3UWoCpBRpurM6LQGmt6tOxwWW+WDz/GOmMeLQEdh10EWMY7Ov2hwyFWSOhCn1cuvZk7/RUjEBlXhjNQ9W2aBd4Rx3vJ4AXaSbX6Py733aLfjbS0khhs9N3cD+nY9o2ibWuE16Xl7pAUJeyq/YPQr3iwm7kAEBgmiuREYj3NQCeUJa+q+dVMg+j4+XxMcw10HcsIXuuqif4RzjDc+7JOEvIzMVOfdjfLDMyQspVyu/RhC0aYWhY8Uyf3np+QgyQOg2fVQFFGU7MG9Os3WG2wZGMVz08vMRg+w8KTmiI/EBsaP8Ot46qG29MAUL4o9Tw5bF4ZZUYzTUz4gkoAT+XFSEMpyqXEz0FdDbRx7mqZSRJ9ufhUbF8m yvQYZsC2 zk0albD7KjLGGkJRy8YDMYsDlnMNlm+hCTqWoNgSUiqPlqwVdR9c4zceRywJ6panhooh0Xwpio77AKdPimY6juxYtMafkiO93UCW68g79+YIGcXFpWls5vaPJJad/OaugCPDAMYkhH5I4OHzlzL7Wt3nc1SV3csBmczVIRhwzZX5SdMo/5QMEubjNRA3dr4obrwovKQtWSyWE/UJH6AohLZXWeApuZokAY27c6mnsxB2HQMQfgZKsLiALXxroZHkDMjgqSUpSu0YZnS7h5/CxeNg1oxFEECmZ5pw/14KI64c9SvinONZwx7chPniTIezs1KRckO7ysrWjCrRG+sFOv2NYmqk0dkmEEUr9sHWFTqC12YxOsJSVQ+MWg/ViPEWn5JDOzUWCQqe7ODVBGnHIBwTHaefoN8MX0zW8fERfV3VXj/d0R5/NQeCigvQNcTnaIYOlS3doDtUC58UZ3yfpoPepfozgXGr+J4HXpty9fM2SbzQ= 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: A socket is pressure-aware when its protocol has pressure defined, that is sk_has_memory_pressure(sk) != NULL, e.g. TCP. These protocols might want to limit the usage of socket memory depending on both the state of global & memcg pressure through sk_under_memory_pressure(sk). While for allocation, memcg pressure will be simply ignored when usage is under global limit (sysctl_mem[0]). This behavior has different impacts on different cgroup modes. In cgroupv2 socket and other purposes share a same memory limit, thus allowing sockmem to burst under memcg reclaiming pressure could lead to longer stall, sometimes even OOM. While cgroupv1 has no such worries. As a cloud service provider, we encountered a problem in our production environment during the transition from cgroup v1 to v2 (partly due to the heavy taxes of accounting socket memory in v1). Say one workload behaves fine in cgroupv1 with memcg limit configured to 10GB memory and another 1GB tcpmem, but will suck (or even be OOM-killed) in v2 with 11GB memory due to burst memory usage on socket, since there is no specific limit for socket memory in cgroupv2 and relies largely on workloads doing traffic control themselves. It's rational for the workloads to build some traffic control to better utilize the resources they bought, but from kernel's point of view it's also reasonable to suppress the allocation of socket memory once there is a shortage of free memory, given that performance degradation is better than failure. As per the above, this patch aims to be more conservative on allocation for the pressure-aware sockets under global and/or memcg pressure. While OTOH throttling on incoming traffic could hurt latency badly possibly due to SACKed segs get dropped from the OFO queue. See a related commit 720ca52bcef22 ("net-memcg: avoid stalls when under memory pressure"). This patch preserves this decision by throttling RX allocation only at critical pressure level when it hardly makes sense to continue receive data. No functional change intended for pressure-unaware protocols. Signed-off-by: Abel Wu --- net/core/sock.c | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index af778fc60a4d..6c1d13547f1b 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -3041,6 +3041,7 @@ EXPORT_SYMBOL(sk_wait_data); int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind) { struct mem_cgroup *memcg = mem_cgroup_sockets_enabled ? sk->sk_memcg : NULL; + bool under_memcg_pressure = false; struct proto *prot = sk->sk_prot; bool charged = false; long allocated; @@ -3051,13 +3052,25 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind) if (memcg) { if (!mem_cgroup_charge_skmem(memcg, amt, gfp_memcg_charge())) goto suppress_allocation; + + /* Get pressure info from net-memcg. But consider the memcg + * to be under pressure for incoming traffic iff at 'critical' + * level, see commit 720ca52bcef22 ("net-memcg: avoid stalls + * when under memory pressure"). + */ + if (sk_has_memory_pressure(sk) && + mem_cgroup_under_socket_pressure(memcg, &under_memcg_pressure) && + !in_softirq()) + under_memcg_pressure = true; + charged = true; } /* Under limit. */ if (allocated <= sk_prot_mem_limits(sk, 0)) { sk_leave_memory_pressure(sk); - return 1; + if (!under_memcg_pressure) + return 1; } /* Under pressure. */ @@ -3087,8 +3100,20 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind) if (sk_has_memory_pressure(sk)) { u64 alloc; - if (!sk_under_memory_pressure(sk)) + /* Be more conservative if the socket's memcg (or its + * parents) is under reclaim pressure, try to possibly + * avoid further memstall. + */ + if (under_memcg_pressure) + goto suppress_allocation; + + if (!sk_under_global_memory_pressure(sk)) return 1; + + /* Trying to be fair among all the sockets of same + * protocal under global memory pressure, by allowing + * the ones that under average usage to raise. + */ alloc = sk_sockets_allocated_read_positive(sk); if (sk_prot_mem_limits(sk, 2) > alloc * sk_mem_pages(sk->sk_wmem_queued +