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 A8F95C433F5 for ; Thu, 10 Mar 2022 17:42:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 329028D0002; Thu, 10 Mar 2022 12:42:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D8088D0001; Thu, 10 Mar 2022 12:42:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1524C8D0002; Thu, 10 Mar 2022 12:42:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 078A38D0001 for ; Thu, 10 Mar 2022 12:42:45 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BD647181C9908 for ; Thu, 10 Mar 2022 17:42:44 +0000 (UTC) X-FDA: 79229196648.17.1A8C2CA Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf02.hostedemail.com (Postfix) with ESMTP id 12F7680023 for ; Thu, 10 Mar 2022 17:42:43 +0000 (UTC) Received: by mail-qt1-f174.google.com with SMTP id v14so904046qta.2 for ; Thu, 10 Mar 2022 09:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/vRO0Bupv5kqM+Ufn91Z/8vO14usV/pASjUe/JVvGIc=; b=Jibfei3OPnbOZzs/F82tGMdHDHzp7cGRzTOhxFBoOkFdRfbgsbaEglWYfM0Ga6VDkx mx79x0YS3fIGSehNcfy9D9RsROLoZ0vPcViNBtl+XSmW6WIcIszZh/9d7rvRRjxSEkWm ZfeZpG/gk+0R95PFoAbbDdHUr3CHsGORtI3ILDmXkzU1YAvY+MeBCufeKadQeu5wOR0W el9oU7H5rz4TV9+GLYbBzNjUGv6GywqHJw2ejA+cXr2SGPvk/phvyHQi2zfw2dm/Qfew LZm09th2OxtlD16Ds4QOYj5oDstMczeeJqO9M/5KTICfe3aId6hKdE0/TVzOAgS3vSPS xN0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=/vRO0Bupv5kqM+Ufn91Z/8vO14usV/pASjUe/JVvGIc=; b=qO22/Wm6h8ESuhBDhx4isSY8FljWBWTfKxC/NDou8IPpyLiFfdGG98G/OFqK+MIpCz 52CMsclxPyxA5Q/p1nlebfY09SlBHNr6Kam0+Ff5qlAVwODWSb0PK4GmnmyUzij8OEcI DZoWtkCGAFv7FP2cpDTkzujTFr8Tm7NhNwm6ot8fQnsft4v+J/U897TCv4azFxwZ0CkG PCfUSIH86G+X2woAFnepgpi4ue62kapS/q1mPkx07W6Jn0VYbeAvkU86/nV0RcsjtKUU CxwjOkcWSjYmU/5OMq5r0Enpqf1aQ1AfToQECqXbQ5ke/r/Dcs/jcPNSd1i3m7daqjGi ling== X-Gm-Message-State: AOAM5315S/GFHqTGNqU41beAY/E1fQ1Sd+e30x8etmSp7G+zNBN8TsAq TPCwKVWf4yDxiH5DB3xa9kEEwA== X-Google-Smtp-Source: ABdhPJzLut3jYT85wv2yG6cjqaZJOVDYAad9Ky1CldHS1t+/T6XaNl7Qth8d8wDTScb/jtiglk0vrw== X-Received: by 2002:a05:622a:1213:b0:2e0:5fe8:542a with SMTP id y19-20020a05622a121300b002e05fe8542amr4930895qtx.347.1646934163217; Thu, 10 Mar 2022 09:42:43 -0800 (PST) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id f34-20020a05622a1a2200b002e1a35ed1desm3099870qtb.94.2022.03.10.09.42.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Mar 2022 09:42:42 -0800 (PST) Date: Thu, 10 Mar 2022 12:42:42 -0500 From: Johannes Weiner To: Wei Xu Cc: David Rientjes , Michal Hocko , Shakeel Butt , Andrew Morton , Yu Zhao , Dave Hansen , Linux MM , Yosry Ahmed , Greg Thelen Subject: Re: [RFC] Mechanism to induce memory reclaim Message-ID: References: <5df21376-7dd1-bf81-8414-32a73cea45dd@google.com> <20220307183141.npa4627fpbsbgwvv@google.com> <63fcd044-7c87-63f3-391e-3b32f8feaae@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 12F7680023 X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=Jibfei3O; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.174 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Stat-Signature: 6p9uc9rmgaau3m46u737hg3yjfj3r3b7 X-HE-Tag: 1646934163-251673 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 Thu, Mar 10, 2022 at 09:33:48AM -0800, Wei Xu wrote: > On Thu, Mar 10, 2022 at 8:58 AM Johannes Weiner wrote: > > > > On Wed, Mar 09, 2022 at 02:03:21PM -0800, David Rientjes wrote: > > > On Tue, 8 Mar 2022, Michal Hocko wrote: > > > > > > > > Let me take a stab at this. The specific reasons why high limit is not a > > > > > good interface to implement proactive reclaim: > > > > > > > > > > 1) It can cause allocations from the target application to get > > > > > throttled. > > > > > > > > > > 2) It leaves a state (high limit) in the kernel which needs to be reset > > > > > by the userspace part of proactive reclaimer. > > > > > > > > > > If I remember correctly, Facebook actually tried to use high limit to > > > > > implement the proactive reclaim but due to exactly these limitations [1] > > > > > they went the route [2] aligned with this proposal. > > > > > > > > I do remember we have discussed this in the past. There were proposals > > > > for an additional limit to trigger a background reclaim [3] or to add a > > > > pressure based memcg knob [4]. For the nr_to_reclaim based interface > > > > there were some challenges outlined in that email thread. I do > > > > understand that practical experience could have confirmed or diminished > > > > those concerns. > > > > > > > > I am definitely happy to restart those discussion but it would be really > > > > great to summarize existing options and why they do not work in > > > > practice. It would be also great to mention why concerns about nr_to_reclaim > > > > based interface expressed in the past are not standing out anymore wrt. > > > > other proposals. > > > > > > > > > > Johannes, since you had pointed out that the current approach used at Meta > > > and described in the TMO paper works well in practice and is based on > > > prior discussions of memory.reclaim[1], do you have any lingering concerns > > > from that 2020 thread? > > > > I'd be okay with merging the interface proposed in that thread as-is. > > We will need a nodemask argument for the memory tiering use case. We > can add it as an optional argument to memory.reclaim later. Or do you > think we should add a different interface (e.g. memory.demote) for > memory tiering instead? Yes, good point. We can add an optional parameter later on, methinks, as the behavior for when it's omitted shouldn't change.