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 F06A7C433EF for ; Mon, 11 Apr 2022 07:20:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C7A46B0072; Mon, 11 Apr 2022 03:20:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69EF26B0073; Mon, 11 Apr 2022 03:20:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 567366B0074; Mon, 11 Apr 2022 03:20:37 -0400 (EDT) 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 498266B0072 for ; Mon, 11 Apr 2022 03:20:37 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 132FD616C5 for ; Mon, 11 Apr 2022 07:20:37 +0000 (UTC) X-FDA: 79343750514.16.7849332 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf24.hostedemail.com (Postfix) with ESMTP id 3F1E8180008 for ; Mon, 11 Apr 2022 07:20:36 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 239E11F38C; Mon, 11 Apr 2022 07:20:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649661635; 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=EKQ22xGnCAfhZWYXu0EvGb4wthBpsfoBSJ1Jf+KqZ/U=; b=ZyojcBVo92JmwvoAqRyuWeNWhRdm2bTVzL3tgs8ML4g9f+5OapIHmsoh8iSO3TZbUFORDW l7lVqpJ+JmozjlZtoMfJjR4SyYzHmgOUP3TOxtkw2i10q7qGLIWBSnvnX/BajoavEbPNJp v/KvnynxlBntXBl4aDgMwxDLnE8Fnlg= 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 68ECBA3B83; Mon, 11 Apr 2022 07:20:34 +0000 (UTC) Date: Mon, 11 Apr 2022 09:20:30 +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: X-Rspam-User: X-Stat-Signature: cgn6izczeie4nkct6u9xeakt1nfg3myh Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ZyojcBVo; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 3F1E8180008 X-HE-Tag: 1649661636-845404 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 10:55:56, Dan Schatzberg wrote: > On Fri, Apr 08, 2022 at 04:11:05PM +0200, Michal Hocko wrote: > > 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? > > Yeah, it just allows you to avoid reading memory.current to just > reclaim everything if you can specify "max" The same could be achieved by requesting a really high number (-1Ul) > - you're still protected > by nretries to eventually bail out. The number of retries is an implementation detail and nobody should really rely on that. Bail out on signal can be still used so yeah getting a large input or whatever alias of that should be just fine. > Mostly, though I just feel like > supporting "max" makes memory.reclaim semetric with a lot of the > cgroup memory control files which tend to support "max". max is used for limits now and this doesn't have a semantic of one. But I have to say I do not really feel strongly about this. -- Michal Hocko SUSE Labs