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 361BCC4332F for ; Thu, 13 Oct 2022 03:34:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 866316B0071; Wed, 12 Oct 2022 23:34:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 814EC6B0073; Wed, 12 Oct 2022 23:34:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B5356B0074; Wed, 12 Oct 2022 23:34:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 563666B0071 for ; Wed, 12 Oct 2022 23:34:13 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1A61E12066A for ; Thu, 13 Oct 2022 03:34:13 +0000 (UTC) X-FDA: 80014507986.18.F39476C Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf19.hostedemail.com (Postfix) with ESMTP id BA4FC1A001A for ; Thu, 13 Oct 2022 03:34:12 +0000 (UTC) Received: by mail-pf1-f175.google.com with SMTP id h13so812963pfr.7 for ; Wed, 12 Oct 2022 20:34:12 -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=XO+97KxgluoajPHIXHQ8Pu1WlMxATOZK61Q8UDagKn4=; b=rWdO99mDYoyhMfakQMEPK+uf/aAGfBGVGzyhKfSU439QvdifZ6wj/XKsaDLMWf3m4G gSj/kPWqNSLyiW6QqYw240jyn7R/0QUabcPB07lJGOK8aLXGBz1jd5EWYkpB6Cii6EQJ /pY6o5SS9Fd7QWhBHUPlSxKpV22NoDk9gZuZyuFY9/D4S5gzLQEBDwMIn5/QkKd81Byk aEllZFOX89wTs+RMadSWYZ4NnPYMlIQ9YkdjAz2XxpRvgNaewbamcUBS+20LQ9gUbe/1 2ebrJ647KK/AEkw+B0k92jmpTH90B5+ksn1qBvT8zKZ/D2XsY0RgitAAUYRS+UfLJThk wZyQ== 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=XO+97KxgluoajPHIXHQ8Pu1WlMxATOZK61Q8UDagKn4=; b=WbymLC25YZkuVHONXxxC9799jbrBC4QeYDtsqVJ55MlsWs4O/XKFvdkpwakUP5k0Cs Yzifi1aKeIQ8kbyrmtED8a4AJJvK6OGdr6g6qekI/y9XPwuau4d+NezlXhTQMVdQLliH gJ97ShURSjPhoTW2fpBkatisLUsYj8u+gVaxopwXcm3zr+LlIEW3RqJn+G4Ql0WU28Tm Iw4nP1dKW7Vb+zzANy6RJ20lMzuF3s0j0YLq3J7EqSl9IBsSvmM8xjxm62sf+R3Y9qAD Tpps4+XbwNlyjFrYMjJifVxArc/12Clfry/LJfbkFfp5SB7G1C73GkfWGKhCwo5YeAE+ 5qCQ== X-Gm-Message-State: ACrzQf26hhia6FcfFzf8a+veEe9iNl2CCCYrM22KqYtcxIZJx1XI1MI+ q2OSpH5iSo48OxA3VFqMaD3UTnAJyav2a8Kxt/Vcfg== X-Google-Smtp-Source: AMsMyM68pkfkjql0u5736BvWl8jC0iqn4gzZliZGCQJ+V8p6w7WpzJYLJ9HKSC2nrbICS2ezhRFKR/P3/5oZUadTCFs= X-Received: by 2002:a05:6a00:cc4:b0:565:e009:b94c with SMTP id b4-20020a056a000cc400b00565e009b94cmr1851123pfv.25.1665632051470; Wed, 12 Oct 2022 20:34:11 -0700 (PDT) MIME-Version: 1.0 References: <20210817194003.2102381-1-weiwan@google.com> <20221012163300.795e7b86@kernel.org> <20221012173825.45d6fbf2@kernel.org> <20221013005431.wzjurocrdoozykl7@google.com> <20221012184050.5a7f3bde@kernel.org> <20221012201650.3e55331d@kernel.org> In-Reply-To: <20221012201650.3e55331d@kernel.org> From: Wei Wang Date: Wed, 12 Oct 2022 20:34:00 -0700 Message-ID: Subject: Re: [PATCH net-next] net-memcg: pass in gfp_t mask to mem_cgroup_charge_skmem() To: Jakub Kicinski Cc: Shakeel Butt , 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665632052; 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=XO+97KxgluoajPHIXHQ8Pu1WlMxATOZK61Q8UDagKn4=; b=Gv2mfqm1tkd2QmJptnQEX6zj/XnCh2yes/v9qXFOS0Ljmrb++YWMPeLDzIBXfpQProwJQT Cv1OHF26Mk59zMH1xFORPwhYc+AGdZj2qwU00Y93RVSN6mEHD0LzMm2fEI2TYEXzuxJn2t MSItsS4xaT4lRcWntXsQv8BmMon76D8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rWdO99mD; spf=pass (imf19.hostedemail.com: domain of weiwan@google.com designates 209.85.210.175 as permitted sender) smtp.mailfrom=weiwan@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665632052; a=rsa-sha256; cv=none; b=oEls5jZ9oUGr64mIQgB6hCyVwDMN8oEpGUR+LeT7nkvTaSZz300yOci1eDdL4LN/oy1Lje OBjyWQunyb51FlShWVTzaKKbMDXFpmTaadZ9ysFqCydf06dda+tRKp/xjgxBZXKEaOmrMR s60I7ORe1E2cnchyWI/PcHo5spZtcLY= X-Rspam-User: X-Rspamd-Queue-Id: BA4FC1A001A X-Stat-Signature: xju8zk6fzxf3qedfw4kjkmqxagchgnu6 Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rWdO99mD; spf=pass (imf19.hostedemail.com: domain of weiwan@google.com designates 209.85.210.175 as permitted sender) smtp.mailfrom=weiwan@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam10 X-HE-Tag: 1665632052-57950 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, Oct 12, 2022 at 8:16 PM Jakub Kicinski wrote: > > On Wed, 12 Oct 2022 18:40:50 -0700 Jakub Kicinski wrote: > > Did the fact that we used to force charge not potentially cause > > reclaim, tho? Letting TCP accept the next packet even if it had > > to drop the current one? > > I pushed this little nugget to one affected machine via KLP: > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 03ffbb255e60..c1ca369a1b77 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -7121,6 +7121,10 @@ bool mem_cgroup_charge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages, > return true; > } > > + if (gfp_mask == GFP_NOWAIT) { > + try_charge(memcg, gfp_mask|__GFP_NOFAIL, nr_pages); > + refill_stock(memcg, nr_pages); > + } > return false; > } > AFAICT, if you force charge by passing __GFP_NOFAIL to try_charge(), you should return true to tell the caller that the nr_pages is actually being charged. Although I am not very sure what refill_stock() does. Does that "uncharge" those pages? > The problem normally reproes reliably within 10min -- 30min and counting > and the application-level latency has not spiked.