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 A1906C4708D for ; Thu, 8 Dec 2022 00:31:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 363468E0005; Wed, 7 Dec 2022 19:31:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3140D8E0001; Wed, 7 Dec 2022 19:31:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DAF08E0005; Wed, 7 Dec 2022 19:31:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0FC988E0001 for ; Wed, 7 Dec 2022 19:31:42 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CDBC7A012F for ; Thu, 8 Dec 2022 00:31:41 +0000 (UTC) X-FDA: 80217260802.11.B31770D Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf29.hostedemail.com (Postfix) with ESMTP id 611C3120016 for ; Thu, 8 Dec 2022 00:31:39 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GcvzBKZH; spf=pass (imf29.hostedemail.com: domain of 3ajCRYwgKCDMhWPZTTaQVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--shakeelb.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3ajCRYwgKCDMhWPZTTaQVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--shakeelb.bounces.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=1670459500; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=phKzW+pnWcxpZMlO+OGC3q3KyWa3Ai371n7pkUjY42s=; b=krGBAEDdqMhdAf0IJkJK6klVuE3R70ZEKfgcyV52b3k0QnWSkoSGzCkeXFm8sK2dbazklS KFE2rQBHc4j4zdu3/voe5P2TcwihpOX353Q82t/ondcNUI3s2D1W8Jme4vsN7vo9IFlzPh r211CHxmHJlnUgls0qzaEm0MqlH1dCE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GcvzBKZH; spf=pass (imf29.hostedemail.com: domain of 3ajCRYwgKCDMhWPZTTaQVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--shakeelb.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3ajCRYwgKCDMhWPZTTaQVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670459500; a=rsa-sha256; cv=none; b=kjD8X2OUWumHySQ+9Aepc1LD75vhCQFQLCiDmvFCjheKQlNJRm5096Kg+mAfHpoX1hhS+R ix6MORVX8SPu8ch2Lp/Gk26X//VQvapsPnXfMME4xeB7mTVvXx924IMa4yd+0BmiZAZYrN dgAuos+vOKjqZZbuya+gHWs9y96qWPQ= Received: by mail-pl1-f202.google.com with SMTP id t1-20020a170902b20100b001893ac9f0feso7625plr.4 for ; Wed, 07 Dec 2022 16:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=phKzW+pnWcxpZMlO+OGC3q3KyWa3Ai371n7pkUjY42s=; b=GcvzBKZHxUPcMbsMIVs11wJmblKLng4iReNp1M5ibs/jGlVOlzs8gse33hKi0r80d3 4py+w8LI+3nJYWK8ZHaSqhXB2Uiak2y9NhC7j3lJ6R1R69as73jNKJKxJH9LiwjI8e1d MetDnMkMhXBRBjs9blHiXf9td0dJKWvI6zm9E3odBEh/Q0aEDhi9QSdUDkbSJu0sBLf7 GmD67NVPCz8BOXn9qmTnJmvuIfl7OIhCFLqkKxmDFJOjrSau5U5GhJqzKYp7SqdjHIFp NH630+6SYXOZNb0eEnqgRPAuNnT0GH0bcEZ+5l/9XRUIU/cBltRovIN/r4VTIfO5+EP9 y2Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=phKzW+pnWcxpZMlO+OGC3q3KyWa3Ai371n7pkUjY42s=; b=iaKHZsyOWKp0MMe5eNNQlWuauSEtUiV5isM7y/kMW1BmSmsU9olzTDmsQSCC/NJVMg Vloer4fAt6LKBZRNuR63bVIBvRM1syIvg/3YeztyW1XywX1+Qh7XYQrXmpK7P8i6Svli uEgrF3mMXX5RRqOP4RQybA9eOo/IMbuGuOt3c2/Bj7uW9LaIAP14z5exDIzN+x+ac1iS b9BzY65FmfIpHCvS2pGfkYxgHHawduf8cZVDeCAhothQZhYtCMG+NSJQcuEqWa1+frtA rL60xnHkCPbhT1UB5TyzIcugs445QMOn1MR1RKh65cgWmz2TIufI3OCpS86NjjE7SYeO TqtQ== X-Gm-Message-State: ANoB5pkZU+Ej6fnrJNNfTdCD9QnhRMkEn56yeOHrVhm7u4bx+vz+QtPw 2+Pk14W/5qiohR+xMnpgI5Rj4i48mVV1Og== X-Google-Smtp-Source: AA0mqf4slF5wuVDt7vcUdSy33m/cV+nfkgqPs0VJCJbPcJEf4NAvlhc1TSDJ3tuFkNkT3zZfDe6ynMVlPbiVGA== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a17:902:9a8a:b0:189:58a9:14a4 with SMTP id w10-20020a1709029a8a00b0018958a914a4mr65845663plp.18.1670459498810; Wed, 07 Dec 2022 16:31:38 -0800 (PST) Date: Thu, 8 Dec 2022 00:31:36 +0000 In-Reply-To: Mime-Version: 1.0 References: <20221206231049.g35ltbxbk54izrie@google.com> Message-ID: <20221208003136.fxm6msgiswl2xdac@google.com> Subject: Re: Low TCP throughput due to vmpressure with swap enabled From: Shakeel Butt To: Johannes Weiner Cc: Eric Dumazet , Ivan Babrou , Linux MM , Linux Kernel Network Developers , linux-kernel , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , "David S. Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Paolo Abeni , cgroups@vger.kernel.org, kernel-team Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 611C3120016 X-Stat-Signature: crn7ffx13b3ak1gour1totzzsnmgsm8j X-Rspam-User: X-HE-Tag: 1670459499-449057 X-HE-Meta: U2FsdGVkX18PkHAhuoQmrPdBgc9T8U6heh+bPIFohKiZJvaO+kwJtBl1aOFqB9KVqYruAlE67o7mRjfqvcbjx1JoJJIVJj7juFKLdqX17Qyigt9pwaKdQxMXcg4OQscPANMdAtx80S3N0UXkhOYZlICGxzktZqjzrH3blbRg59nbfiY65QPIbBSGcRdnUWf/WPbhKVQIeHW/ILIAhRJIaDcYHJqJioKyfDhrs45QdkWGyY9C4iuuAwCs4vdyXQfG5pOhIaVBAvFeli89w5LDCUqMfRY/pHbIVrGEvOCGSdOHHdNudoH/eItSE/G5UoNmsh5JtnRmCaycWshFTaqgTuZ4lBiQWWb3o4yL9eJQ/cuggMfyv0mMWuCMbDKUZZ4EfAzV/lHEJWxDU0OGiX+/hQFPwowDM0BA4DZP6PCAxHyUNWwwM43p3hENzoTH7XE6VyxvYOpF+lDb2qNSfPrAHOwf9vLCctwAcvuFp4gK9Yo6mLuChu1LATFhGCvBHszM6w+uL0aGzEL1ZYW04lMWfJfh4lO6dKPhxZRfe/ShTgqSV2ifkxuaVw+HNF595K+x7ClVlxG/clRBKwU5sggIbHxXOwvdOVifmjNBPiiGRXorXqqMYIpffY06bz8gwEkn5DqBodhAnuFqqxdR6PJi437g/p7pEZqNFzqJnFOXouH2MfuY5ONYrPv8jODQBLZsMdrK8wA61cFh1ffJSVvMvrSTeTLDZWB1sF+mcxcu/fWxZMrkknA6TPdYkea1wFEwLJtvMMgculzNrQ3ke+fSWOaBLE2TwlaoTY9f8gtL1qnx7m+k3JSY9Pfql67FeYU0a4QQWkTm+2iGV0MaBLLxXLY6GthuVsr2udXDk933YBs23DIfJZyiPySn7d0X6anRxIt+PcTlkwJrU8ouQJgNKE7KSN3uzCjDj2888SN4DH/VGezD8llStLNpA0V9Cl3niZiGIS8W0mYK2Vp36QR Xr4ivqEl 5kjJa/H9/yaHOBlrv8Ncq4fpR3ea+JlFc8yM4oyHAtehgijmA3e1XZoFW0rO5bfQ2rBGC0IYE1WHnEXKJ4/yMej8Uoqa8XKYgBZb1zLiuRjDBcKclLpoG3BQafL+jXIZH3o/jFLK5FQqaP6whb1zq6JJm2zx8xblqEfPKcwmNmeePdlZVQXuojjy9tASfHHKSotiowdfOtViHEY59kGgf/Ck7uwhyM7uv4uljqU2cdo+9VIxeBwiSW5rLy5HfKcM2hx3wb9O3ih7jZ23sNidkbodjSkSYzoF8WRTQqZ6xI5IuM7wbLVkvsyyZNdroTA2SZhYHgb+SFsBM2Cw4tGiRH2vA5ANvUZwXnkF5e/UaWHx8h6dftKeY3a2Pn1z3pKqZ9J9j 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: 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