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 CC59DC433FE for ; Thu, 13 Oct 2022 00:54:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A6F06B0071; Wed, 12 Oct 2022 20:54:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32EB56B0073; Wed, 12 Oct 2022 20:54:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A8AE6B0074; Wed, 12 Oct 2022 20:54:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F36C06B0071 for ; Wed, 12 Oct 2022 20:54:36 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BD3C9ABA35 for ; Thu, 13 Oct 2022 00:54:36 +0000 (UTC) X-FDA: 80014105752.08.BF2235B Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) by imf13.hostedemail.com (Postfix) with ESMTP id 4EC772002B for ; Thu, 13 Oct 2022 00:54:36 +0000 (UTC) Received: by mail-pg1-f202.google.com with SMTP id x16-20020a63b210000000b0045f5c1e18d0so159931pge.0 for ; Wed, 12 Oct 2022 17:54:35 -0700 (PDT) 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=2tlT0sKryIjjlYcEvRxXBonCj9sjgTZRO4xGVKaegZc=; b=aCC+5QU5Q6ql86BpxO4LEXx32nPTesKN2ifqvcP4ePLuU4LSDEC9aC5PcOyvEq0Tio lT95CTcSyY026VFVEPc6wa5F7zF2cYv2M5AG9//2M0Jv5R1mSTFLzZd3QK5pWtPWjvTQ 7QdVXzB93hHMtr7jFlS7ez4Ze2Me5JUuBRa69ctkMF1i478rc2j4UC7ms1mvWEBNs3pT PgKUPt8lLz2rUP4Zf688haPjC7tU0IPluU6wxir/wOA2bL6EJo0hXIA49VJMvK3Q5WiC DkXwUroV44w0bjwTtglFGghxbDo7MVzZouxftAmhHGb/0j79QDmmff0E+hnfPrMPoZ40 UAFQ== 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=2tlT0sKryIjjlYcEvRxXBonCj9sjgTZRO4xGVKaegZc=; b=F/BfXyFLxuz9FD7P5fEP5gUBPQv+356XhP/gj8xAojmu/PcRPH9DZyYu7sMdJtDqzQ ULG2CFfK7/TGjJhhNG40vI7pAj7thJUc33JvRnLRziCP7oLT8WjpHwUZuSRTcyuGL2yM 5poid15mRUbhhl+XTYdK+2uuUo9tKMJZ57VcUBOe13WvXQtxhJaZP9rzlBj4XNiEUb6o SuMOn6OisStUHnxifSIm1a95sbCZUb6cTEKCAWjO/Q2fv9bA5JIIPTDT5639hBR6ZSpI cZQrNe1daJz+wukAkEOsesTMtbihOeho7rOUaMlhMvm8VwH9yGMVTMtmoCtoBPPHY/ai IAOQ== X-Gm-Message-State: ACrzQf3Moc6OQGPz7oL4UqtRBm2nV3jcxOsIn7I5XD6JcyjiQUQxVDAD WB5erf2s3RvdJu1TjfNBl8gT0ZWMywi8yw== X-Google-Smtp-Source: AMsMyM5X/Dl+9DA/7md7Osvy7DxGRQ4FWuzTQwkehXz6q6IsmTu6BxBQHm1VBP9Dh364YU9mjaQoHnsoVaMkVA== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a17:903:11c4:b0:178:634b:1485 with SMTP id q4-20020a17090311c400b00178634b1485mr31147763plh.142.1665622475078; Wed, 12 Oct 2022 17:54:35 -0700 (PDT) Date: Thu, 13 Oct 2022 00:54:31 +0000 In-Reply-To: <20221012173825.45d6fbf2@kernel.org> Mime-Version: 1.0 References: <20210817194003.2102381-1-weiwan@google.com> <20221012163300.795e7b86@kernel.org> <20221012173825.45d6fbf2@kernel.org> Message-ID: <20221013005431.wzjurocrdoozykl7@google.com> Subject: Re: [PATCH net-next] net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem() From: Shakeel Butt 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="us-ascii" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665622476; a=rsa-sha256; cv=none; b=GSvMXZJr012sNc5mkg2ZKt3LaJuSiAewFgUWTZCHvDZOiCJ9E2SN7FybVBMiTb133+Aqzr ucog6TXTBeDZFQPGm2IY7qXg3JliQ7zB3q1M3Ci2i7wdDwVkPofMXqLwPfCZRR5oYmsD9J ikNPoSizsMaIfg2abztXGLtP0g6MBR0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=aCC+5QU5; spf=pass (imf13.hostedemail.com: domain of 3y2FHYwgKCMwAzs2ww3ty66y3w.u64305CF-442Dsu2.69y@flex--shakeelb.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3y2FHYwgKCMwAzs2ww3ty66y3w.u64305CF-442Dsu2.69y@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=1665622476; 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=2tlT0sKryIjjlYcEvRxXBonCj9sjgTZRO4xGVKaegZc=; b=xT4YSPwVk1gUcfFpShAZV9x+k8v8K1T76LioGekdq5XRUSH9cEs6CZtvE1T6ePo27qRBIT qJCZvYDveLizk0oId2y0Xk9XFN0IxBovLDbjRbabuYv04qWLgXDkAms7FtHpW9VbY61wWs QkSlv5tMwwJHnxiGwMPEbesHxLbDrEY= X-Stat-Signature: 8zegjma89m9ja51ghz1kq6s7csrj5p5m X-Rspamd-Queue-Id: 4EC772002B X-Rspam-User: X-Rspamd-Server: rspam08 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=aCC+5QU5; spf=pass (imf13.hostedemail.com: domain of 3y2FHYwgKCMwAzs2ww3ty66y3w.u64305CF-442Dsu2.69y@flex--shakeelb.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3y2FHYwgKCMwAzs2ww3ty66y3w.u64305CF-442Dsu2.69y@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1665622476-591930 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000130, 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 05:38:25PM -0700, Jakub Kicinski wrote: > On Wed, 12 Oct 2022 17:17:38 -0700 Shakeel Butt wrote: > > 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. > > We're talking TCP here, to be clear. I haven't tested a revert, yet (not > that easy to test with a real workload) but I'm relatively confident the > change did introduce an "unforced" call, specifically this bit: > > @@ -2728,10 +2728,12 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind) > { > struct proto *prot = sk->sk_prot; > long allocated = sk_memory_allocated_add(sk, amt); > + bool memcg_charge = mem_cgroup_sockets_enabled && sk->sk_memcg; > bool charged = true; > > - if (mem_cgroup_sockets_enabled && sk->sk_memcg && > - !(charged = mem_cgroup_charge_skmem(sk->sk_memcg, amt))) > + if (memcg_charge && > + !(charged = mem_cgroup_charge_skmem(sk->sk_memcg, amt, > + gfp_memcg_charge()))) > > where gfp_memcg_charge() is GFP_NOWAIT in softirq. > > The above gets called from (inverted stack): > tcp_data_queue() > tcp_try_rmem_schedule(sk, skb, skb->truesize) > tcp_try_rmem_schedule() > sk_rmem_schedule() > __sk_mem_schedule() > __sk_mem_raise_allocated() > > Is my confidence unjustified? :) > Let me add Wei's explanation inline which is protocol independent: __sk_mem_raise_allocated() BEFORE the above patch is: - mem_cgroup_charge_skmem() gets called: - try_charge() with GFP_NOWAIT gets called and failed - try_charge() with __GFP_NOFAIL - return false - goto suppress_allocation: - mem_cgroup_uncharge_skmem() gets called - return 0 (which means failure) AFTER the above patch, what happens in __sk_mem_raise_allocated() is: - mem_cgroup_charge_skmem() gets called: - try_charge() with GFP_NOWAIT gets called and failed - return false - goto suppress_allocation: - We no longer calls mem_cgroup_uncharge_skmem() - return 0 So, before the patch, the memcg code may force charges but it will return false and make the networking code to uncharge memcg for SK_MEM_RECV.