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 DDA0EC4332F for ; Thu, 13 Oct 2022 00:17:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39A106B0071; Wed, 12 Oct 2022 20:17:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 349A96B0074; Wed, 12 Oct 2022 20:17:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21D026B0071; Wed, 12 Oct 2022 20:17:52 -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 0EAFF6B0071 for ; Wed, 12 Oct 2022 20:17:52 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D533340DE7 for ; Thu, 13 Oct 2022 00:17:51 +0000 (UTC) X-FDA: 80014013142.18.2D251C4 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf04.hostedemail.com (Postfix) with ESMTP id 7780A40027 for ; Thu, 13 Oct 2022 00:17:51 +0000 (UTC) Received: by mail-yb1-f179.google.com with SMTP id 81so305058ybf.7 for ; Wed, 12 Oct 2022 17:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Nqgh1ED8YLB3Lt0ws7IuNLmuxoK0yD2LR5GJPgsLVvA=; b=W1fbXQ4scCa8Aep6N0cQa85yRo+RHzhCjqU9C17a2GycoxpJKqsfwyTzqPU2P9Dgpa +l6W0OriU9nSD1VENAfnSKXeF274+lr4SyUHODPMPW2x3a8jcaKK9+eZV2uJWHoMir0T Vcx+kXS6Eqbpe7DbkwjZ49mEerz1hwPFIz8Ld0q/CoGVyfL/1HWyro0i9LugpgS4AXKN ign/P4AP/BpuWW/cHBjxOLuuTfXFsSMCMu8SHFtP5vt3KgodzfzfTUgJNCrxYR9bI9xY oUh275VlEVNfw+4YPxMuIedrLbqw9kCSZ7O2Z9Kd9snkSpDjZi3iJw9nDl14QfXbGHXd Q7Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Nqgh1ED8YLB3Lt0ws7IuNLmuxoK0yD2LR5GJPgsLVvA=; b=APaWSq1R3SE2uGDrVGQM0KGruDAun4M1pu2HyFLisS763fX6fLQj2MHxhALkgLV7yh d4UmAAKRh92qmiHe/tEMVusTza55ELpYeCCLABLMpwgMeJHfr+LguQa+fhyF9Uxx1JqG ju9ezQh0KY8yWn+Xfe5sbSh4OU57Q5ahd0VG4cB6J8V2oSP3Y2MM/JuDMi1jpfu69S3h +RXQ6FftldRHXc+5p1U2dRIywU8pW2YrPkt/Uasf+HX9+GF+rbXt/NCqvDwqLT5YaTpp +3rD6ZLxT3HGnVWwWu8lSLCp52sYbryCmbxtvwaTN92bWitELDa5dk7gMsBBTH25xGfk cObg== X-Gm-Message-State: ACrzQf33SUj5+CI82eAfLfduyBZWmHdY0qdmDiSohxcU99xPc+gDwsOm /SkiHsH1e29OHoBEkDMXCkWn/2DMbMneLkZTSLzbgw== X-Google-Smtp-Source: AMsMyM5Xnza8VEtFbrhcq72guYOiwZzbACy5/YLx5pQbN6BpBeTecfpkREpBFpJHdWAl173DTnZHrkaj5NX6U0SFseo= X-Received: by 2002:a25:9885:0:b0:6b3:e9a7:4952 with SMTP id l5-20020a259885000000b006b3e9a74952mr32358446ybo.294.1665620270607; Wed, 12 Oct 2022 17:17:50 -0700 (PDT) MIME-Version: 1.0 References: <20210817194003.2102381-1-weiwan@google.com> <20221012163300.795e7b86@kernel.org> In-Reply-To: <20221012163300.795e7b86@kernel.org> From: Shakeel Butt Date: Wed, 12 Oct 2022 17:17:38 -0700 Message-ID: Subject: Re: [PATCH net-next] net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem() To: Jakub Kicinski Cc: Wei Wang , Eric Dumazet , netdev@vger.kernel.org, "David S . Miller" , cgroups@vger.kernel.org, linux-mm@kvack.org, Roman Gushchin Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=W1fbXQ4s; spf=pass (imf04.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665620271; a=rsa-sha256; cv=none; b=19dJtfX9ZiAYFIzbM1fAlDo18hLdk1chaM4FA494nNXQ9C5a+mqJgYMJ5TFzOkWfxkFh+3 a2e81mP0k8YL4c3reizuGr3htEqO64dAXPOezrEWHJ1odx+7j5mVBvS4Yfof04N8I7mCOQ V/uYnLoTFsKchtFPxGTW4Z5bYGHiptE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665620271; 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=Nqgh1ED8YLB3Lt0ws7IuNLmuxoK0yD2LR5GJPgsLVvA=; b=k+PHDTgAfr2Uzi9jrai07cXQDLEeMz3fajiuoH9n9P7XUlefHJ9MFXDQjTtqpzfRkIZIGo UEJYYAs15rCFJJP7kn+LIepUR6l4bdCR3nXAx6iJ6qnR4xVVKyX8pityM4r9+wz00cR88V Ts/3Y8VZBVlWbkoRqUp7JEpn78eM2+M= X-Rspamd-Queue-Id: 7780A40027 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=W1fbXQ4s; spf=pass (imf04.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Stat-Signature: uhjfrs6dcyi6wqcs3s8qqjnx6pmdeh9p X-HE-Tag: 1665620271-784375 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000061, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 12, 2022 at 4:33 PM Jakub Kicinski wrote: > > On Tue, 17 Aug 2021 12:40:03 -0700 Wei Wang wrote: > > 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 decide > > 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. > > This patch is causing a little bit of pain to us, to workloads running > with just memory.max set. After this change the TCP rx path no longer > forces the charging. > > Any recommendation for the fix? Setting memory.high a few MB under > memory.max seems to remove the failures. Did the revert of this patch fix the issue you are seeing? The reason I am asking is because this patch should not change the behavior. Actually someone else reported the similar issue for UDP RX at [1] and they tested the revert as well. The revert did not fix the issue for them. Wei has a better explanation at [2] why this patch is not the cause for these issues. [1] https://lore.kernel.org/all/CALvZod5_LVkOkF+gmefnctmx+bRjykSARm2JA9eqKJx85NYBGQ@mail.gmail.com/ [2] https://lore.kernel.org/all/CAEA6p_BhAh6f_kAHEoEJ38nunY=c=4WqxhJQUjT+dCSAr_rm8g@mail.gmail.com/