Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2955870pxb; Mon, 4 Apr 2022 04:07:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmbbbI8Y2KbfDM/hgf1DhrxWqjh7iHbubFws5AvhN9kMeiMUhB9MWQ5QrER/yMFzrIE9kU X-Received: by 2002:a50:d6c9:0:b0:41a:68bf:ff26 with SMTP id l9-20020a50d6c9000000b0041a68bfff26mr32447960edj.102.1649070478189; Mon, 04 Apr 2022 04:07:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649070478; cv=none; d=google.com; s=arc-20160816; b=q1TfmtbcKThKLSEchNaUWv4g6g7s5ziWl1UqsgMx1Zb6FkDpGmPSUH0Srwm+GoLzqf jFNzoC72xjFAhJnLdsMB81IjNaOqMP8rWTxQ/xPP77emTV/dmktREnSIniQ6nUFhkz4F i/wzK8jWoWFoMh8zqD++GOHfi8c1foSlGfMmVclAWpepX6Bb9YBKE2NUDsN3NVvF1d4K g/+87bz7J7oxjdc3/5+BKbZEdx37fAYcgBtADosL/GzQLMbXUOdCwYNN+PSUfC6Rm+fp 1Sz3svn7Wypeeen+bX+upnCdkSYl5Yt1/egvG7nyKzjWcyHCFUC1YL/1ptGROYnqiNmi 4kkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=hJ9w0vjGF60hV1jwTCwkmqKMT8MPf1xtJXL++UES4qY=; b=pgoaA77tgRqaNpaEa8Pc4tqAExnCxyWarFkEeE9hCq53lupJBd9jJQTF/GPpm5cN1c JvPpny3s8gVnM0AZe0pZSYndxDGIjb29ifdAX7qhBUVXZYA2rEmZAtcjrqUnOTAem8fP OV+myYTyHjTfcbZl8Zs+Zc08ypTfeJuDQiFwGibs9CdmnakXDFBUR8buy6mFjAysyhxi v+us8K/G/AMVeuHSEhIfxsJVV/6tRI+RQYOKtXeLdvU/W4IKZEEw76HDYOaxFOJh6GzS N4YiVCs9AE4Vas7sldtqe3belzy84HDsWdlsPxMRc3nSj1dvBQcM5R2YRkJ7AB8AC3+8 yCBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sdZWMtzH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x13-20020a170906b08d00b006df76385dd0si6431178ejy.624.2022.04.04.04.07.33; Mon, 04 Apr 2022 04:07:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sdZWMtzH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244685AbiDADkq (ORCPT + 99 others); Thu, 31 Mar 2022 23:40:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244681AbiDADkl (ORCPT ); Thu, 31 Mar 2022 23:40:41 -0400 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98A2B580C7 for ; Thu, 31 Mar 2022 20:38:49 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id g21so1804173iom.13 for ; Thu, 31 Mar 2022 20:38:49 -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=hJ9w0vjGF60hV1jwTCwkmqKMT8MPf1xtJXL++UES4qY=; b=sdZWMtzHnJv1VHTyDpKpYUwNhjIuI9a7tcXI/FgRTIIZ5ukpZ4YE1gzZ4NIwUJ/yLW ontK0twBtMRgMUAuB3XoVPBxkx1u8ljBY3neVZ/ZbKwoxvvOmtITTYduYFewRSwCrzgg 9ZgIB9ihjVZADAfyBSTxCQxVJHg0wEwL+QsxHCNc5OYHJcDV1fFk4tAcv81F2UhtPley Hncdj/WWY39C2l70OUJY7Tby2YvHAG4c/hVHDFx4R78Dj60TZX/eDiMRa82AM73wK7wh xP5FKWMZLhlqm3Z4lOn+c0+dLNADzkK1dadFETFvblqC8MQuUarqI4R43OmYEFbg22nl MCwg== 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=hJ9w0vjGF60hV1jwTCwkmqKMT8MPf1xtJXL++UES4qY=; b=DP/b9AB+AZB2z8C9/HkQvwxzW1gWCBu9EypiOG3vMkLCWz1xyLnyhjsPMa2FXGQA0H PcYlihCYHhj8wcO0lCJ5gvoQkBPjfeTxPdBz2jwlG8dQPhVtrk8b22F1NE2rc3b8+3p+ ykJW3kEEaKv/+NM0OhSpioI6CkufSS2XyUsL/iJbaIayqb1KW2eKKuu9oLrBGNMaTF46 QFp/etWSRgbXytYEIRGXUqi3usxxwK1cqO0fOvBm23QzCMjhs9rYK6YQBik2Z4YDA37n iJU7uS2/auw+ulxa+AzKjENFv9EZ+z2ZigtFxtzJUTQek51HUQ6F2i5y5TTOR2mx46pC DgTA== X-Gm-Message-State: AOAM530IWUup7TRHRWgTj1WFHkTSAvqSMO3M7CI8Tn2szS3HrzKueXKO CMrajiZJa2tTnT0iLGOTVO0J2y3GMoN0L6HCCh8t7g== X-Received: by 2002:a05:6638:3012:b0:317:9a63:ecd3 with SMTP id r18-20020a056638301200b003179a63ecd3mr4934731jak.210.1648784329202; Thu, 31 Mar 2022 20:38:49 -0700 (PDT) MIME-Version: 1.0 References: <20220331084151.2600229-1-yosryahmed@google.com> <20220331173350.1fe09370479a4a6f916b477d@linux-foundation.org> In-Reply-To: <20220331173350.1fe09370479a4a6f916b477d@linux-foundation.org> From: Wei Xu Date: Thu, 31 Mar 2022 20:38:38 -0700 Message-ID: Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface To: Andrew Morton Cc: Yosry Ahmed , Johannes Weiner , Michal Hocko , Shakeel Butt , David Rientjes , Tejun Heo , Zefan Li , Roman Gushchin , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , Linux MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 31, 2022 at 5:33 PM Andrew Morton wrote: > > On Thu, 31 Mar 2022 08:41:51 +0000 Yosry Ahmed wrote: > > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -6355,6 +6355,38 @@ static ssize_t memory_oom_group_write(struct kernfs_open_file *of, > > return nbytes; > > } > > > > +static ssize_t memory_reclaim(struct kernfs_open_file *of, char *buf, > > + size_t nbytes, loff_t off) > > +{ > > + struct mem_cgroup *memcg = mem_cgroup_from_css(of_css(of)); > > + unsigned int nr_retries = MAX_RECLAIM_RETRIES; > > + unsigned long nr_to_reclaim, nr_reclaimed = 0; > > + int err; > > + > > + buf = strstrip(buf); > > + err = page_counter_memparse(buf, "", &nr_to_reclaim); > > + if (err) > > + return err; > > + > > + while (nr_reclaimed < nr_to_reclaim) { > > + unsigned long reclaimed; > > + > > + if (signal_pending(current)) > > + break; > > + > > + reclaimed = try_to_free_mem_cgroup_pages(memcg, > > + nr_to_reclaim - nr_reclaimed, > > + GFP_KERNEL, true); > > + > > + if (!reclaimed && !nr_retries--) > > + break; > > + > > + nr_reclaimed += reclaimed; > > + } > > Is there any way in which this can be provoked into triggering the > softlockup detector? memory.reclaim is similar to memory.high w.r.t. reclaiming memory, except that memory.reclaim is stateless, while the kernel remembers the state set by memory.high. So memory.reclaim should not bring in any new risks of triggering soft lockup, if any. > Is it optimal to do the MAX_RECLAIM_RETRIES loop in the kernel? > Would additional flexibility be gained by letting userspace handle > retrying? I agree it is better to retry from the userspace.