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 013D7C433F5 for ; Fri, 8 Apr 2022 20:09:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CF706B007B; Fri, 8 Apr 2022 16:09:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17F636B007D; Fri, 8 Apr 2022 16:09:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD98B6B007E; Fri, 8 Apr 2022 16:09:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id D13EC6B007B for ; Fri, 8 Apr 2022 16:09:04 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 81981AAAEF for ; Fri, 8 Apr 2022 20:09:04 +0000 (UTC) X-FDA: 79334800608.29.FC8E14A Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf19.hostedemail.com (Postfix) with ESMTP id 1F6B31A000A for ; Fri, 8 Apr 2022 20:09:03 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id f3so9354253pfe.2 for ; Fri, 08 Apr 2022 13:09:03 -0700 (PDT) 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=lps+VNBxsxLTQEq6nQohZpJYqrkqH9hvkhZrZvs8ibQ=; b=RCf6vfwHloKvazwXoXjT3SbJbG6javpXCWAOqpmzI5xWQaDqYTQcsOMEQ207Cos5B5 qO9ltnjeXz+TlC6P6gS5antoHVMaIZrCQ11eHYBSz4eTQ/R5GGKOKUyFI3+806vxMnK1 fbXlyPceUpjETNwwV/acg+2NG+XN7k8bQEJSHpWLS+RnyRLA9cOOAyhj2wlwHqa6fXhX 5UzERtidt5e1I1tW46oeIC+BAKtd/hL8cz2X59EFfp/FyB0bvhoBiag+huSUtmzW0EGF ZloCHuXwEcJaDEAdLae+GRpT74s5Z5tB2VxWhFW/wTLF+JzkDyExAWJEJn5dCTzRM2C4 T/4g== 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=lps+VNBxsxLTQEq6nQohZpJYqrkqH9hvkhZrZvs8ibQ=; b=08W+Yjnj/Gaujymi+ZXWRbhDtN4GkoAM/Vqwl63hJbnWNy2WAbNZjrepQC0anedrdC LGcIkkgDtu/KC5Z0MO1I6/bfwR6sdrPOKGXTxqoT/hI79CyewwFHPorglbm9ZmSzA0qQ lF5nrGiG731YWASH0UY8Xn8WtXqtXYEIEQLwOumu+2qGS65FMJUN6R0POv35pq56qJaV ooOLp6ZNRMfdWj946M3K4YpTyqg+lS2okxaTO7Fj9LPKetB80LJ1UqmD9D+V1XI6OFB8 molT4cP11cTCneowpJDlbdsaf12m93LxWxQGSbwPsNqk7L8rCiOhi/y5bR7p0RHLCcxx FeiA== X-Gm-Message-State: AOAM530XIHRnkqq3L5834Op8o6aFLJQ9jFJw2K6JKc5/z3ULM9LL0rOo g02gGOCvgZtyTgTnyYredG9NfmMxrbNId75JDp0djQ== X-Google-Smtp-Source: ABdhPJzz7VtU/jWLapetzfgx+tJK9xG2ELYFWCgBlgjsJVs1zlzEQ0TGnJccuDT8XjoFmwm+1J8zGhZZ1ZeuNlXpWT0= X-Received: by 2002:a63:ff63:0:b0:386:327:5353 with SMTP id s35-20020a63ff63000000b0038603275353mr16630830pgk.401.1649448542724; Fri, 08 Apr 2022 13:09:02 -0700 (PDT) MIME-Version: 1.0 References: <20220408045743.1432968-1-yosryahmed@google.com> <20220408045743.1432968-2-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 8 Apr 2022 13:08:26 -0700 Message-ID: Subject: Re: [PATCH v3 1/4] memcg: introduce per-memcg reclaim interface To: Dan Schatzberg , Michal Hocko Cc: Johannes Weiner , Shakeel Butt , Andrew Morton , Roman Gushchin , David Rientjes , Tejun Heo , Zefan Li , Jonathan Corbet , Shuah Khan , Yu Zhao , Dave Hansen , Wei Xu , Greg Thelen , Chen Wandun , Vaibhav Jain , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Tim Chen , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , Linux-MM , linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: r7yrxxd9iwqroxhsb4t8eurgf1rqtzyh Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RCf6vfwH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of yosryahmed@google.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspamd-Queue-Id: 1F6B31A000A X-HE-Tag: 1649448543-340151 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 Fri, Apr 8, 2022 at 7:55 AM Dan Schatzberg wrote: > > On Fri, Apr 08, 2022 at 04:11:05PM +0200, Michal Hocko wrote: > > Regarding "max" as a possible input. I am not really sure to be honest. > > I can imagine that it could be legit to simply reclaim all the charges > > (e.g. before removing the memcg) which should be achieveable by > > reclaiming the reported consumption. Or what exactly should be the > > semantic? > > Yeah, it just allows you to avoid reading memory.current to just > reclaim everything if you can specify "max" - you're still protected > by nretries to eventually bail out. Mostly, though I just feel like > supporting "max" makes memory.reclaim semetric with a lot of the > cgroup memory control files which tend to support "max". One possible approach here is to have force_empty behavior when we write "max" to memory.reclaim. From Google's perspective we don't have a preference, but it seems to me like logical behavior. We can do this either by directly calling mem_cgroup_force_empty() or just draining stock and lrus in memory_reclaim(). This actually brings up another interesting point. Do you think we should drain lrus if try_to_free_mem_cgroup_pages() fails to reclaim the request amount? We can do this after the first call or before the last one. It could introduce more evictable pages for try_to_free_mem_cgroup_pages() to free.