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 C77C1C433F5 for ; Mon, 4 Apr 2022 09:08:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349602AbiDDJJ6 (ORCPT ); Mon, 4 Apr 2022 05:09:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244472AbiDDJJy (ORCPT ); Mon, 4 Apr 2022 05:09:54 -0400 Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64B113BA61; Mon, 4 Apr 2022 02:07:58 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id 85so7057106qkm.9; Mon, 04 Apr 2022 02:07:58 -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=4bEukbCR9Nhs/phBw9CHkxQ3EgSEHMJ/cxKPyV/U1Lc=; b=J5KW87ePrm1kVWM8zimS7BHw2Mzubr83uLPX1ZBEuTOjvvs+UkzK/GsTYtS+rkeeh6 Ge2jgAndu7+Zy91oVbelB/tQnEdNrikZagGfuskZmImTjrfeZFKVfsqjT4l6uBHJSGVZ VY7S7PBo+y7RdG666XUW2bx1aEo7G3ouf2K51+rUsGOhwYYyquxLNq9RdgI6zt+EI6Oq QogUEwbMxBtv/3Hc+6E7ikZQLShJTywcEZtzSZ40mqOmq5LwKkAGxigcH/x8JoioykXi D2BAEjI17KvY0X1MbUap3yVxXSGf+QKh6gAAsi1h7CMfZADAjRdbrxbuASmFKV+ZXIG/ gb5Q== 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=4bEukbCR9Nhs/phBw9CHkxQ3EgSEHMJ/cxKPyV/U1Lc=; b=H4MVPRHZpoZkOQgT7Fhaa1Rt7ZKwHQoVYSuvI/MzfOgPoCUCtWoedhLCjcIHK2UvZn FFo6VPNUn1+HghjFfgooWer0TcmLIIu5TlwUQuSnP1/fWu9WgTvlXNynJREobB3WjxGx 2geSWQ7d6iYeqIU0OkuwG8ahNzOVe26XLrE5H13S27tXyu6Et9TUKlzq6XIt2Wack4t/ KVDIYipR24ADFQRxE2+LI455QTtJqyeDggYxnrL8PgyTcm9xwQ8DUKhRTITvnQL1QGYK gGlNQ9i7k4hvx5CtIQbHbjc0IxzisCr7EBTmdbWs9JOv82fxpF7NmfQ2p69zNYs2chNQ C74Q== X-Gm-Message-State: AOAM530yn+s7L3M8Gn31G1uvY+AOhKky0KVM5UsClMM29v3qfDN0Wy8n ZYBeSjN0NLnNaxsvM+15EEpKUXtGWlso0myLDYcscShav4dA7A== X-Google-Smtp-Source: ABdhPJzxhreJVMKs5S5FdXqt1xixG6+tcI/PtSb1hJfCARG67fDZF716ric68cm5HwCcmcK69tuvoAk4ghPFTca0/L0= X-Received: by 2002:a05:620a:108f:b0:67b:465f:56ba with SMTP id g15-20020a05620a108f00b0067b465f56bamr13401510qkk.297.1649063277536; Mon, 04 Apr 2022 02:07:57 -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:07:30 +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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhaoyang Huang Subject: Re: [RFC PATCH] cgroup: introduce dynamic protection for memcg Date: Mon, 4 Apr 2022 17:07:30 +0800 Message-ID: References: <1648713656-24254-1-git-send-email-zhaoyang.huang@unisoc.com> Mime-Version: 1.0 Return-path: 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=4bEukbCR9Nhs/phBw9CHkxQ3EgSEHMJ/cxKPyV/U1Lc=; b=J5KW87ePrm1kVWM8zimS7BHw2Mzubr83uLPX1ZBEuTOjvvs+UkzK/GsTYtS+rkeeh6 Ge2jgAndu7+Zy91oVbelB/tQnEdNrikZagGfuskZmImTjrfeZFKVfsqjT4l6uBHJSGVZ VY7S7PBo+y7RdG666XUW2bx1aEo7G3ouf2K51+rUsGOhwYYyquxLNq9RdgI6zt+EI6Oq QogUEwbMxBtv/3Hc+6E7ikZQLShJTywcEZtzSZ40mqOmq5LwKkAGxigcH/x8JoioykXi D2BAEjI17KvY0X1MbUap3yVxXSGf+QKh6gAAsi1h7CMfZADAjRdbrxbuASmFKV+ZXIG/ gb5Q== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: Suren Baghdasaryan , "zhaoyang.huang" , Andrew Morton , Johannes Weiner , Vladimir Davydov , "open list:MEMORY MANAGEMENT" , LKML , cgroups mailinglist , Ke Wang 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. > > > 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