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 3908AC433EF for ; Tue, 5 Apr 2022 12:08:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 707B36B0071; Tue, 5 Apr 2022 08:08:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B8246B0073; Tue, 5 Apr 2022 08:08:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 557CA6B0074; Tue, 5 Apr 2022 08:08:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id 45CB46B0071 for ; Tue, 5 Apr 2022 08:08:35 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 03BBF8249980 for ; Tue, 5 Apr 2022 12:08:25 +0000 (UTC) X-FDA: 79322702970.27.7092030 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf23.hostedemail.com (Postfix) with ESMTP id 9867914003E for ; Tue, 5 Apr 2022 12:08:24 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 34FB4210EF; Tue, 5 Apr 2022 12:08:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649160503; 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=VYOi21VBdrnEfgCIXqKolf+TBqlw4Pd+D8zmojzTZKg=; b=IzlVwj1UBmMOQmHd3Zp7EfAXZmHByCFtW1hb2ofyTRxldgM0qGnGQd6hQt8jCSab/6KcQa DvpaN+BbZ0cPKEbNjPfbufOi006FMFq43iNjeXx+OsbgAgJLj9TyIVm1NfWnLhJysJp1ob x43XW5Auch1IHBKqWUSgRQ4Q6Do+kNI= 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 81C8CA3B89; Tue, 5 Apr 2022 12:08:22 +0000 (UTC) Date: Tue, 5 Apr 2022 14:08:21 +0200 From: Michal Hocko To: Zhaoyang Huang Cc: Suren Baghdasaryan , "zhaoyang.huang" , Andrew Morton , Johannes Weiner , Vladimir Davydov , "open list:MEMORY MANAGEMENT" , LKML , cgroups mailinglist , Ke Wang Subject: Re: [RFC PATCH] cgroup: introduce dynamic protection for memcg Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=IzlVwj1U; spf=pass (imf23.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-Stat-Signature: 7wo4ug4w5py36xy4ra9phmerqbybgodf X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9867914003E X-HE-Tag: 1649160504-338337 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 04-04-22 21:14:40, Zhaoyang Huang wrote: [...] > Please be noticed that this patch DOES protect the memcg when external > pressure is 1GB as fixed low does. This is getting more and more confusing (at least to me). Could you describe the behavior of the reclaim for the following setups/situations? a) mostly reclaiming a clean page cache - via kswapd b) same as above but the direct reclaim is necessary but very lightweight c) direct reclaim makes fwd progress but not enough to satisfy the allocation request (so the reclaim has to be retried) d) direct reclaim not making progress and low limit protection is ignored. Say we have several memcgs and only some have low memory protection configured. What is the user observable state of the protected group and when and how much the protection can be updated? I think it would be also helpful to describe the high level semantic of this feature. > Besides, how does the admin decide > the exact number of low/min if it expand from small to even xGB in a > quick changing scenario? This is not really related, is it? There are different ways to tune for the protection. [...] -- Michal Hocko SUSE Labs