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 EAAF1C433EF for ; Thu, 10 Feb 2022 22:25:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E4896B0074; Thu, 10 Feb 2022 17:25:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7931D6B0075; Thu, 10 Feb 2022 17:25:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 634676B0078; Thu, 10 Feb 2022 17:25:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id 560C26B0074 for ; Thu, 10 Feb 2022 17:25:15 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0B38A8249980 for ; Thu, 10 Feb 2022 22:25:15 +0000 (UTC) X-FDA: 79128302190.21.9C79C00 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf23.hostedemail.com (Postfix) with ESMTP id A0225140007 for ; Thu, 10 Feb 2022 22:25:14 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id f23so13082257lfe.5 for ; Thu, 10 Feb 2022 14:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+9taNQqr53065W1oX4JDNtAk/+njpm3x8DzxRxP1lHU=; b=D959OvVwl7BXuwDxGu0YH5B8iaG9JycwJXSActYL0Rhkvl1XpSclE6R6SP/TS9KpOb uIITo6yOM2u/NW7Lpt2qvugxdahKXm7DxUSfw4CvZOax6yiLj0PuPiJD0kxUvrCoLRZE 8+tEADL2hNCtlzAphVfr0GXuxsruicxdkryZKu4A3EZQYGNy1YGT2PXBJWQ7cmvCU5sT JmTq6TyMVzqerdn7CZcyv983bkS+4BRuAEOfAWl2vQTFGVVjXWYx7YXbhJ8zrn9tghSq n6Z4aZpGnza7LI6CgiHjzXoxAuxZQeb8ZX3fWnC9sHKXTbS9MAdJvXlr3WYwA+ZhdPb1 7tbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+9taNQqr53065W1oX4JDNtAk/+njpm3x8DzxRxP1lHU=; b=oNAFpAZ5MgkfL+GAcXXFEeJAugUW5ZUkDZouMapgiFAGdBd+hagcQ+rMfOk1/QkdHf Wu3oLsixZ4kIPFgdb9Q/7/wJWdC768UgbYo8GsR/W0+WqRpl5Fza87luhAoR0SOnhAI1 vr/KbLOuBPyXPrhygUDBYiGIzHINnnGFZ7A8ki2jPTyTKCMtBUhKVp6ULdVt+suDOCSN GNca6/pk0NjytkCEq3+trARFy2lmI3ShA6VW97UaTDSNi5mQq5b7GW/385Yp2xMNP3cf TO2RN369l5vZA7fSHyQjRVNcRMx9vI+K5hr/krYHgZmCVE42LsMK3kZ1Qpp95JbLXCi3 jOZw== X-Gm-Message-State: AOAM532uHumo1X30MGmRcxm8o4QmAHna7B00m3qoMIiyFIR1T5s1obW3 V+KhDpqztBrbLg02gs7x4QVeq90/T0gTGa9pRcHjyA== X-Google-Smtp-Source: ABdhPJyM1osoqKEaHQe/4Fm9kFoRNB8nnlkgffkyJW13U9ZE2XGrrPprjfDe61hw1PjYuIsv/WI+Ymv70pU4S4b9iCg= X-Received: by 2002:ac2:43ad:: with SMTP id t13mr6592317lfl.8.1644531912995; Thu, 10 Feb 2022 14:25:12 -0800 (PST) MIME-Version: 1.0 References: <20220210081437.1884008-1-shakeelb@google.com> <20220210081437.1884008-3-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Thu, 10 Feb 2022 14:25:01 -0800 Message-ID: Subject: Re: [PATCH 2/4] memcg: unify force charging conditions To: Roman Gushchin Cc: Johannes Weiner , Michal Hocko , Chris Down , Andrew Morton , Cgroups , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=D959OvVw; spf=pass (imf23.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: z8qoq1pijuoky657o4odbiutim7au5oq X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A0225140007 X-Rspam-User: X-HE-Tag: 1644531914-72056 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000625, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 10, 2022 at 12:03 PM Roman Gushchin wrote: > > On Thu, Feb 10, 2022 at 12:14:35AM -0800, Shakeel Butt wrote: > > Currently the kernel force charges the allocations which have __GFP_HIGH > > flag without triggering the memory reclaim. __GFP_HIGH indicates that > > the caller is high priority and since commit 869712fd3de5 ("mm: > > memcontrol: fix network errors from failing __GFP_ATOMIC charges") the > > kernel let such allocations do force charging. Please note that > > __GFP_ATOMIC has been replaced by __GFP_HIGH. > > > > __GFP_HIGH does not tell if the caller can block or can trigger reclaim. > > There are separate checks to determine that. So, there is no need to > > skip reclaim for __GFP_HIGH allocations. So, handle __GFP_HIGH together > > with __GFP_NOFAIL which also does force charging. > > This sounds very reasonable. But shouldn't we check if __GFP_DIRECT_RECLAIM > is set and bail out otherwise? > We already have a gfpflags_allow_blocking() check which checks for __GFP_DIRECT_RECLAIM.