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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45F36C433EF for ; Fri, 1 Apr 2022 09:18:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344441AbiDAJT5 (ORCPT ); Fri, 1 Apr 2022 05:19:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237873AbiDAJTz (ORCPT ); Fri, 1 Apr 2022 05:19:55 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F40C266B5C for ; Fri, 1 Apr 2022 02:18:05 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id gp15-20020a17090adf0f00b001c7cd11b0b3so4792885pjb.3 for ; Fri, 01 Apr 2022 02:18:05 -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=CcE1vZsqOC27RAHXsaotKwbu3NGWTU8/jzgbrphRdpE=; b=L+wRmwtFkpd+m0tszgzRoGykDP58MklBTX07/cJ3alDFu0VTSd1I/hq/zSMXHjhGd+ ORsn1KzqqogGVi4mEaAioTilnjtqw+9fiL/T5mhdsV7F09NJgeLoW1Pong3lb9u44HlH heu2mrTDcicJ+vo4LfufK5AN8/JHVWx4UZTgexfGuT74z4KNunHe8Z7/XU3izLZfSuhA lrUtAomJfqUQvzsXIXGjLIZxE9YtIHnpOVXrDNjcg9V3wHsMcNWLnx0N9xjIIXeb2MIW E242uqzwCdo3qulMfbGnkEpwGOgq94HkLWTJXXR5Dj/7x5mDcvtd59PD1MalZ/0jqiJz yT+w== 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=CcE1vZsqOC27RAHXsaotKwbu3NGWTU8/jzgbrphRdpE=; b=QHAShddvpbVfvw09DmVpoBm5HFAeqVhe4067Dsx+oov1FruGTTIo37KUnb14s2XROC rdgVTxYaX/j5iqZbcan9U8y8xNJ8OHeH9i9UE1eBn7jHQqKg7OzOWDGWxvb4VwVukR/v QZiNEQspHJu1paiUf7ROvk6UYzv6TvgHAFD94pKeiDVrGE/7o8pu/vUxAPcBHYW7AyPj hBqCTCPoRCzhg/0GHHHwXuMa/Bz4LG+Rjuxd+LPmuBmkIRhiYkmesX76GB5SU1BAFif0 Z009VzYb28Fhs/08Yiuci3O4RkzXyIKDtbXcwKrUSgIEDzFSQs8v8fISfVH8dzh+PnpQ EWKA== X-Gm-Message-State: AOAM530zRCLXQvFUf811wYcHLjcz3lHMSLx0oCAJXbziEmCIABmaILcH H0Y6TOzKgJfcbeIY9w6rT50hdQeiPYD9yLoUpkIxDg== X-Google-Smtp-Source: ABdhPJzIcbBBYmnkH3+FpntCyPdMrtDjlssU8PqFqE4s/EVCA8z8gJO+XVwbeP3Q/W5eRtmJH46bL1QGzljwG3Suleg= X-Received: by 2002:a17:903:2341:b0:156:196a:3ef with SMTP id c1-20020a170903234100b00156196a03efmr9330941plh.81.1648804684807; Fri, 01 Apr 2022 02:18:04 -0700 (PDT) MIME-Version: 1.0 References: <20220331084151.2600229-1-yosryahmed@google.com> <20220331173350.1fe09370479a4a6f916b477d@linux-foundation.org> In-Reply-To: From: Yosry Ahmed Date: Fri, 1 Apr 2022 02:17:28 -0700 Message-ID: Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface To: Wei Xu Cc: Andrew Morton , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 31, 2022 at 8:38 PM Wei Xu wrote: > > 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. Thanks Andrew and Wei for looking at this. IIUC the MAX_RECLAIM_RETRIES loop was modeled after the loop in memory.high as well. Is there a reason why it should be different here? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yosry Ahmed Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface Date: Fri, 1 Apr 2022 02:17:28 -0700 Message-ID: References: <20220331084151.2600229-1-yosryahmed@google.com> <20220331173350.1fe09370479a4a6f916b477d@linux-foundation.org> Mime-Version: 1.0 Return-path: 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=CcE1vZsqOC27RAHXsaotKwbu3NGWTU8/jzgbrphRdpE=; b=L+wRmwtFkpd+m0tszgzRoGykDP58MklBTX07/cJ3alDFu0VTSd1I/hq/zSMXHjhGd+ ORsn1KzqqogGVi4mEaAioTilnjtqw+9fiL/T5mhdsV7F09NJgeLoW1Pong3lb9u44HlH heu2mrTDcicJ+vo4LfufK5AN8/JHVWx4UZTgexfGuT74z4KNunHe8Z7/XU3izLZfSuhA lrUtAomJfqUQvzsXIXGjLIZxE9YtIHnpOVXrDNjcg9V3wHsMcNWLnx0N9xjIIXeb2MIW E242uqzwCdo3qulMfbGnkEpwGOgq94HkLWTJXXR5Dj/7x5mDcvtd59PD1MalZ/0jqiJz yT+w== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Wei Xu Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Shakeel Butt , David Rientjes , Tejun Heo , Zefan Li , Roman Gushchin , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel Mailing List , Linux MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Greg Thelen On Thu, Mar 31, 2022 at 8:38 PM Wei Xu wrote: > > 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. Thanks Andrew and Wei for looking at this. IIUC the MAX_RECLAIM_RETRIES loop was modeled after the loop in memory.high as well. Is there a reason why it should be different here?