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 0875EC433F5 for ; Fri, 8 Apr 2022 14:11:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A6606B0074; Fri, 8 Apr 2022 10:11:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 757018D0005; Fri, 8 Apr 2022 10:11:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61DD68D0001; Fri, 8 Apr 2022 10:11:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 4EB976B0074 for ; Fri, 8 Apr 2022 10:11:11 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 1DF3B82B63 for ; Fri, 8 Apr 2022 14:11:11 +0000 (UTC) X-FDA: 79333898742.04.6423423 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf08.hostedemail.com (Postfix) with ESMTP id 73480160004 for ; Fri, 8 Apr 2022 14:11:10 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 19956210EE; Fri, 8 Apr 2022 14:11:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649427069; 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=gNPsT3NKhlXnfi2F2vg55Kv/xhOi4VGOL+j6MMtTFeQ=; b=cfXqbCqyXyBa9orgccUoy4424ix9hLjiTcErReYj3EGVeVskbNNPsd6jezIUyblN1T6VI/ /PKqJNKcV+Av8NjuXjYKDNOPjnnWzy0/mCCms8pAaSht4wSV42B5hoL2fPkU54vQzpRJeZ ikVj76De+BwGGpCsVa7bGeTVBr4jiS0= 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 4364AA3B83; Fri, 8 Apr 2022 14:11:08 +0000 (UTC) Date: Fri, 8 Apr 2022 16:11:05 +0200 From: Michal Hocko To: Dan Schatzberg Cc: Yosry Ahmed , Johannes Weiner , Shakeel Butt , Andrew Morton , Roman Gushchin , David Rientjes , Tejun Heo , Zefan Li , Jonathan Corbet , Shuah Khan , Yu Zhao , Dave Hansen , Wei Xu , Greg Thelen , Chen Wandun , Vaibhav Jain , Michal =?iso-8859-1?Q?Koutn=FD?= , Tim Chen , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v3 1/4] memcg: introduce per-memcg reclaim interface Message-ID: References: <20220408045743.1432968-1-yosryahmed@google.com> <20220408045743.1432968-2-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=cfXqbCqy; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 73480160004 X-Stat-Signature: utsusc1narwo8iqff1w7zbqtxrxzasg7 X-HE-Tag: 1649427070-612055 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 08-04-22 09:43:03, Dan Schatzberg wrote: > On Fri, Apr 08, 2022 at 04:57:40AM +0000, Yosry Ahmed wrote: > > +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); > > Is there a reason not to support "max"? Empty string seems odd to me > here. I have to say I have missed the special meaning of the empty string here and I agree this would indeed really weird. Does cgroup core even call here? cgroup_file_write seems to drop !nbytes input. Regarding "max" as a possible input. I am not really sure to be honest. I can imagine that it could be legit to simply reclaim all the charges (e.g. before removing the memcg) which should be achieveable by reclaiming the reported consumption. Or what exactly should be the semantic? -- Michal Hocko SUSE Labs