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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6479C3527B for ; Tue, 5 Apr 2022 21:09:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243908AbiDEVIF (ORCPT ); Tue, 5 Apr 2022 17:08:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352628AbiDENHD (ORCPT ); Tue, 5 Apr 2022 09:07:03 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B1E48300A; Tue, 5 Apr 2022 05:08:24 -0700 (PDT) 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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