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 3EE65C433EF for ; Wed, 9 Mar 2022 22:03:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A07018D0002; Wed, 9 Mar 2022 17:03:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B5DC8D0001; Wed, 9 Mar 2022 17:03:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8574A8D0002; Wed, 9 Mar 2022 17:03:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 7838F8D0001 for ; Wed, 9 Mar 2022 17:03:24 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 506D220408 for ; Wed, 9 Mar 2022 22:03:24 +0000 (UTC) X-FDA: 79226224728.07.4195953 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf21.hostedemail.com (Postfix) with ESMTP id C02FC1C001D for ; Wed, 9 Mar 2022 22:03:23 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id z3so3158408plg.8 for ; Wed, 09 Mar 2022 14:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=wavjm8SVDugVtSDqreuEI8tSq2vDvw/+dHbIx/2MjgY=; b=G1Iu4VydydWUODwJJ+dBWUN6Wxi9DRal/d491uGB5J+kRJa/JQ5Vn+243x1v/q4wlj SAkjAuH914/fCLhnfatrBoPd7wJGn0KHmPBUS9LA1fKggk2Vo5E8mnGPIcMGHzluwrfQ c/zqtz0caj2lMyXwNX31hXB5VupkTKEI2oMYwc9NOQJorbxkZKfGjRDdpqlVxf17B+Ja xsG7UHfk3KyV+Iml7RLVzc4yc78+G9QSsnmSc7rw4GlPt0TAKjIoPTS1CKyuXp5H2F3r 1/uLUNVaRT/TQ5A4ByVldxHODPvY9EChmVzS7GSLnFB80LpyThEhTf8iBPa0ExRJ99RZ cSMg== 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:in-reply-to:message-id :references:mime-version; bh=wavjm8SVDugVtSDqreuEI8tSq2vDvw/+dHbIx/2MjgY=; b=tewzRSB/KPYSh9e+WI9RBYFJxMxZLb4zoaLUJfn+5/rymfN13olUbgCbjINDA6qM1W tiMtMMoGdkdZct7ba5lYbb3CPnrd+69tetPaFsosXyj1RPYFGp2Vv3LRKo3erNplMuQ8 Rrr01evoTMriHCk4vYX7sAHDEPI4zqaExNjG8tVexP6xCS5TcfNihPwvhDKp/iPf1ESL 7vF2nAwP/xG5BZTSQqQJhD53GpvQlBSjPI/bn5+n22+IQ5XPfrUL7IOzXpAe0SMMlbzX l8IJSuhFDYaguagzwD+BuDWRDKfk+ySAZqQo6bo0CYLleabBUh3tb1937nXXK+/g1hPF WTug== X-Gm-Message-State: AOAM530h7KlmOobGpCVkXs1DWmmPqxKPrSQNUj8KmRof+43PKVINRa75 yKtbD2Lst8pAmRIq9UV+uFPNcQ== X-Google-Smtp-Source: ABdhPJwigh66dZo1FspxZBpx7ZoxYwB/N7cQ6zev0Qz530mHPaXQBo/GVkmBSXDwXvrTmUNF/DOtUA== X-Received: by 2002:a17:902:ec8e:b0:152:939:ac4a with SMTP id x14-20020a170902ec8e00b001520939ac4amr1812265plg.5.1646863402531; Wed, 09 Mar 2022 14:03:22 -0800 (PST) Received: from [2620:15c:29:204:9181:7c9:2e7e:9306] ([2620:15c:29:204:9181:7c9:2e7e:9306]) by smtp.gmail.com with ESMTPSA id m16-20020a056a00081000b004f7673dd4b1sm1153385pfk.220.2022.03.09.14.03.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 14:03:22 -0800 (PST) Date: Wed, 9 Mar 2022 14:03:21 -0800 (PST) From: David Rientjes To: Michal Hocko cc: Shakeel Butt , Andrew Morton , Johannes Weiner , Yu Zhao , Dave Hansen , linux-mm@kvack.org, Yosry Ahmed , Wei Xu , Greg Thelen Subject: Re: [RFC] Mechanism to induce memory reclaim In-Reply-To: Message-ID: <63fcd044-7c87-63f3-391e-3b32f8feaae@google.com> References: <5df21376-7dd1-bf81-8414-32a73cea45dd@google.com> <20220307183141.npa4627fpbsbgwvv@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: C02FC1C001D X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=G1Iu4Vyd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of rientjes@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=rientjes@google.com X-Stat-Signature: 8mh31cyrs1km8ehoceddemr4atqi496g X-HE-Tag: 1646863403-441203 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 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? My first email in this thread proposes something that can still do memcg based reclaim but is also possible even without CONFIG_MEMCG enabled. That's particularly helpful for configs used by customers that don't use memcg, namely Chrome OS. I assume we're not losing any functionality that your use case depends on if we are to introduce a per-node sysfs mechanism for this as an alternative since you can still specify a memcg id? [1] https://lkml.org/lkml/2020/9/9/1094