Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3468202pxb; Mon, 4 Apr 2022 17:56:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxead8M0wNjrYsd+M6z3fT1ExlJv0qRLlrWE3ED288kj2MNC/sOewh8iC0V/M99SEBbesgZ X-Received: by 2002:a63:78ca:0:b0:398:ae5:6515 with SMTP id t193-20020a6378ca000000b003980ae56515mr716555pgc.345.1649120213616; Mon, 04 Apr 2022 17:56:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649120213; cv=none; d=google.com; s=arc-20160816; b=oWDwfEI5ZmK5iWW3pRVeSfPTbzvyvshvlNihpA3Jh6CARoCIZBTWjrytUw0B5HKxxR BAJiKXbqPoev/K2LIyTg7zNsl3rGJ5CtWXN/V2KWvJA+Bj5lIUNrrv7x98Z3zaBniYE4 FrLyp0pPmB5HujDeDYy144KH9LUrhcDFOW3NZaEDd9LtAa2xXR8/imHsgCZ5eNUHeSTB rXvBchayKXtHC3LZrF3fXS/ShslTgaRVYnnSNU1pHZNyosYOEOUhP+Z3LNYs9H7Zjtx9 RZh4Th2Q4RDhVLqV+amKb+FJcHjFcir3CcynKMrTZgAuJ59shj1FsU6KpJEuqdljn8NL F4Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=8dVesPMKaUut+TR+yGDooheAhutrkDr3IKERwS5AoSk=; b=ig55qqouYwQ79FbMXTbgdKl+zgJP1EVzduv416ZRqig+FqxO3QnaFa5DAQ/tF0VOvy t622cZTyLhvLmr0UFdpvaR0nksIBmYC5ETY7xgrPHHa3DZl1JMPYDicfuh6x0BZfhIYY 2nAVbccHc6VvkN/TnMurANRrQihBVO9kgeRTCY6r9jk7sgkvcIpFpCZoPK999L/lbNW8 K+q/YscT3+2FHu4iOhClQ0sf4jF0aOdH9VUqOT09dVm+mL9JXt4C5fG0wmLVdq58yMRv hqqB1mx+QIMhJoCMgGsX3MnwooVtyxMhrAQO+uGc5cms4ipltBkbKqqRaPDR2ohERU/Z dwSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=llLqVXQV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id a23-20020a630b57000000b003825f9cfbcasi12090861pgl.776.2022.04.04.17.56.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 17:56:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=llLqVXQV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0B46A132E98; Mon, 4 Apr 2022 17:03:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243175AbiDDIxr (ORCPT + 99 others); Mon, 4 Apr 2022 04:53:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239368AbiDDIxp (ORCPT ); Mon, 4 Apr 2022 04:53:45 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 810131E3D2; Mon, 4 Apr 2022 01:51:50 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 3A8BF1F37E; Mon, 4 Apr 2022 08:51:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649062309; 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=8dVesPMKaUut+TR+yGDooheAhutrkDr3IKERwS5AoSk=; b=llLqVXQVAuNVhRTxpopykvgOo5UDxL0+UVttQORgi7aeqOzxr0beKggQRRtiym8WzDZ4Qt GbJRJ10wLx240JOdmPbpx+/0eROIKFzQSN+bI6CSp2pTBrhNp1eNW3sGqfCOjn9fiS01bc 30ovvrP+E6SgyIM6U5zj5D9JlKi04HM= 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 B5AF2A3B87; Mon, 4 Apr 2022 08:51:48 +0000 (UTC) Date: Mon, 4 Apr 2022 10:51:48 +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: <1648713656-24254-1-git-send-email-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 04-04-22 10:33:58, Zhaoyang Huang wrote: [...] > > One thing that I don't understand in this approach is: why memory.low > > should depend on the system's memory pressure. It seems you want to > > allow a process to allocate more when memory pressure is high. That is > > very counter-intuitive to me. Could you please explain the underlying > > logic of why this is the right thing to do, without going into > > technical details? > What I want to achieve is make memory.low be positive correlation with > timing and negative to memory pressure, which means the protected > memcg should lower its protection(via lower memcg.low) for helping > system's memory pressure when it's high. I have to say this is still very confusing to me. The low limit is a protection against external (e.g. global) memory pressure. Decreasing the protection based on the external pressure sounds like it goes right against the purpose of the knob. I can see reasons to update protection based on refaults or other metrics from the userspace but I still do not see how this is a good auto-magic tuning done by the kernel. > The concept behind is memcg's > fault back of dropped memory is less important than system's latency > on high memory pressure. Can you give some specific examples? > Please refer to my new version's test data > for more detail. Please note that sending new RFCs will just make the discussion spread over several email threads which will get increasingly hard to follow. So do not post another version until it is really clear what is the actual semantic you are proposing. -- Michal Hocko SUSE Labs