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 79AADC433EF for ; Mon, 4 Apr 2022 09:24:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF5826B0072; Mon, 4 Apr 2022 05:24:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA56F6B0073; Mon, 4 Apr 2022 05:24:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C46238D0001; Mon, 4 Apr 2022 05:24:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id AFFC86B0072 for ; Mon, 4 Apr 2022 05:24:22 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 72C89AD6D4 for ; Mon, 4 Apr 2022 09:24:12 +0000 (UTC) X-FDA: 79318660344.28.D399031 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf28.hostedemail.com (Postfix) with ESMTP id D498CC000A for ; Mon, 4 Apr 2022 09:24:11 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id z19so7191932qtw.2 for ; Mon, 04 Apr 2022 02:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oXmJJ5+eLXFpFacDKNV9S+2RH6HTol71eIq9kzYo+Zo=; b=eflAGqZ3vQTJxGYGbegq1IkJ1Jj7j6sR79EJcRJ6tIr2aMi/46tQdVwR8fYN2kOQ6J nfQxDRXc/vXsD9gMO2zhmgXzpaKvpmvzWAAfTcrbg4tvTH7tlhyQWYf79I58B/XnndMj dqSrGuAjJ5M78Z9iFuUgLFORB8JJgOBV3fBG9y4Cn14m6plu7SILNcI8fjKS+q2PqjVY rRjvDhiqoZGTDrU9QfgdRJYjejVuxOIrZpoQjwNiMHk1nt2vCrHa/tHYVOdynIYpS50B KkQl3sZ+bobm6bOMiqJlOeZibzkmAseeD4kLYm+6giD17MjEbmDDIZjtI6s7BuhgfCNu xVIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oXmJJ5+eLXFpFacDKNV9S+2RH6HTol71eIq9kzYo+Zo=; b=2ABCJIKVFW8dMeUrjfZa5QMotm++F3ev5i2Jm4lWr63ObuaSQuR3q6YdulcBmUTcaA c1eDFpUaAk61qPNP5CuCWw49Gy+IHG8nXkYnia+2ulbzGwD7A2qZUOZzLAkDrFojeOSW sttImKPr1W7Hb90Bvhdx7goyJfVqQJaouPCnKSaf2X2yDm6TlE2mHA6veuQa64xq7ev3 BQAGHoTgfTgrxHC7YIUU0LIKa1Bt8j5LhkoqCdQsc0nvgSbkvcQSpcTmliPpHcWm+jtQ grj/N6qL4Z6IF561KZmqLDuCfKT5rokMR8CyFuZ6dskzoekbSbIagM1+3G3ZAaOTPs6q lJBw== X-Gm-Message-State: AOAM5338AolPybYsyDy5s7C1DUCiroXxQCJrBoEyjSFXxIvOo22yru/I YtjKRblwz784ZS0WyBXLSBfR6Zt+Gh3sv/lpIlw= X-Google-Smtp-Source: ABdhPJzG+pfiihbIr+vV8nmCAu3EUwjBSNALuPSw7wTFpTdkCugi7Vlp+jba89JnUXgvjEkbVMTeI+53Oi+i8WofzDI= X-Received: by 2002:ac8:4e50:0:b0:2e2:17a8:2ab0 with SMTP id e16-20020ac84e50000000b002e217a82ab0mr16600488qtw.68.1649064251177; Mon, 04 Apr 2022 02:24:11 -0700 (PDT) MIME-Version: 1.0 References: <1648713656-24254-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Mon, 4 Apr 2022 17:23:43 +0800 Message-ID: Subject: Re: [RFC PATCH] cgroup: introduce dynamic protection for memcg To: Michal Hocko Cc: Suren Baghdasaryan , "zhaoyang.huang" , Andrew Morton , Johannes Weiner , Vladimir Davydov , "open list:MEMORY MANAGEMENT" , LKML , cgroups mailinglist , Ke Wang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: hbtixhz4h9ihjp5k9179gjspezmyrtxn Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=eflAGqZ3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Rspamd-Queue-Id: D498CC000A X-HE-Tag: 1649064251-978800 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, Apr 4, 2022 at 5:07 PM Zhaoyang Huang wrote: > > On Mon, Apr 4, 2022 at 4:51 PM Michal Hocko wrote: > > > > 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? > For both of the above two comments, please refer to the latest test > result in Patchv2 I have sent. I prefer to name my change as focus > transfer under pressure as protected memcg is the focus when system's > memory pressure is low which will reclaim from root, this is not > against current design. However, when global memory pressure is high, > then the focus has to be changed to the whole system, because it > doesn't make sense to let the protected memcg out of everybody, it > can't > do anything when the system is trapped in the kernel with reclaiming work. Does it make more sense if I describe the change as memcg will be protect long as system pressure is under the threshold(partially coherent with current design) and will sacrifice the memcg if pressure is over the threshold(added change) > > > > > 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. > ok, I will hold until all question done. > > > > -- > > Michal Hocko > > SUSE Labs