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 30AD4C433F5 for ; Tue, 26 Apr 2022 08:22:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 857AE6B0073; Tue, 26 Apr 2022 04:22:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 807C56B0074; Tue, 26 Apr 2022 04:22:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D2116B0075; Tue, 26 Apr 2022 04:22:48 -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 5D3F56B0073 for ; Tue, 26 Apr 2022 04:22:48 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 33A8825D56 for ; Tue, 26 Apr 2022 08:22:48 +0000 (UTC) X-FDA: 79398339216.25.3A93A13 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf05.hostedemail.com (Postfix) with ESMTP id 4B2E810004D for ; Tue, 26 Apr 2022 08:22:41 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 357091F380; Tue, 26 Apr 2022 08:22:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1650961366; 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=NKbpFjMDPqd7TQ514NLGknGrSkR1xvTuZ+twvGBw1Ds=; b=Ku8RBnA0Rf9zQsz4S8BTrgHF20lahZ8buxMT5bsutog3s+qQEzlQpjXalln29/WK/9rWTe y/9DNr88hxHzQwcPkYA9KVTaL8FZ7DTVb/ZbTuzWAufvvhtv6te6DXO8ZUj85HjsIehW/n qbSDE3xjlsTQgKOtmALRZ+WjV1K1F3E= 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 2BB612C146; Tue, 26 Apr 2022 08:22:45 +0000 (UTC) Date: Tue, 26 Apr 2022 10:22:42 +0200 From: Michal Hocko To: Yosry Ahmed Cc: David Rientjes , Johannes Weiner , Shakeel Butt , Andrew Morton , Roman Gushchin , 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 Mailing List , Linux-MM , linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 1/4] memcg: introduce per-memcg reclaim interface Message-ID: References: <20220425190040.2475377-1-yosryahmed@google.com> <20220425190040.2475377-2-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Ku8RBnA0; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4B2E810004D X-Rspam-User: X-Stat-Signature: hw1eyho1ann3uczm5mzf55yqxykh7do7 X-HE-Tag: 1650961361-163394 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 Mon 25-04-22 12:31:51, Yosry Ahmed wrote: > On Mon, Apr 25, 2022 at 12:15 PM David Rientjes wrote: [...] > > "can over or under reclaim from the target cgroup" begs the question of > > how much more memory the kernel can decide to reclaim :) I think it's > > assumed that it's minimal and that matches the current implementation that > > rounds up to SWAP_CLUSTER_MAX, though, so looks good. > > > > Thanks Yosry! > > I think it could be more complex than this. Some functions that get > called during reclaim only use the nr_to_reclaim parameter to check if > they need one more iteration, but not to limit the actual reclaimed > pages per say. For example, nr_to_reclaim is not even passed to > shrink_slab() or mem_cgroup_soft_limit_reclaim(), so they have no way > to know that they should stop if nr_to_reclaim was already satisfied. > I think the general assumption is that each of these calls normally > does not reclaim a huge number of pages, so like you said, the kernel > should not over-reclaim too much. However, I don't think there are > guarantees about this. There are no guarantees indeed and it si definitely good to be explicit about that so that userspace tools expect that and consider that in the imeplementation. Sure we do not want to go overboard and huge excess should be considered a bug. I am not sure we do agree on the notion of "huge" so let's see. -- Michal Hocko SUSE Labs