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 9AE58C433FE for ; Fri, 1 Apr 2022 13:03:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FA998D0002; Fri, 1 Apr 2022 09:03:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 983498D0001; Fri, 1 Apr 2022 09:03:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FDA88D0002; Fri, 1 Apr 2022 09:03:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0009.hostedemail.com [216.40.44.9]) by kanga.kvack.org (Postfix) with ESMTP id 6A6F08D0001 for ; Fri, 1 Apr 2022 09:03:24 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2A52F825FCDF for ; Fri, 1 Apr 2022 13:03:14 +0000 (UTC) X-FDA: 79308325908.20.4151396 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf04.hostedemail.com (Postfix) with ESMTP id 62E5E40060 for ; Fri, 1 Apr 2022 13:03:12 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 0CD4E1FCFF; Fri, 1 Apr 2022 13:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1648818191; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=L8Fv6ZDQ8m+qPC8dDpr3Y/+f6kvNVrRdMcIsE+f6ZEU=; b=lubng6AuK16ZqODySVuFbAIiNelcW5AfzZgr4sNsal07K8TvFn3bNcchUYwkoBlOMOeKLp BtLjH2snjDWIO1W3RF9RbkPDG+a/s+0v1MjSq4/BODP/3y/3mddKI4fF4Hxdnm1mZcB+1b hW0uhc+1XDp1BKTMZ1QPAnz025krtu8= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 59DE7A3B87; Fri, 1 Apr 2022 13:03:10 +0000 (UTC) Date: Fri, 1 Apr 2022 15:03:09 +0200 From: Michal Hocko To: Yosry Ahmed Cc: Wei Xu , Andrew Morton , Johannes Weiner , 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 Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface Message-ID: References: <20220331084151.2600229-1-yosryahmed@google.com> <20220331173350.1fe09370479a4a6f916b477d@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 7ghnjro55h1hfkrhgyh97msmpj31pedx X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 62E5E40060 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=lubng6Au; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: X-HE-Tag: 1648818192-735711 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 01-04-22 02:17:28, Yosry Ahmed wrote: > 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. Memory reclaim already has cond_resched even if there is nothing reclaimable. See shrink_node_memcgs > > > 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? No, I would go with the same approach other interfaces use. I am not a great fan of MAX_RECLAIM_RETRIES - especially when we have a bail out on signals - but if we are to change this then let's do it consisently. -- Michal Hocko SUSE Labs