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 87C45C433F5 for ; Fri, 25 Mar 2022 03:03:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D70516B0071; Thu, 24 Mar 2022 23:03:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1F276B0073; Thu, 24 Mar 2022 23:03:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBF6A6B0074; Thu, 24 Mar 2022 23:03:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id AD0116B0071 for ; Thu, 24 Mar 2022 23:03:17 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 508ACA4DC7 for ; Fri, 25 Mar 2022 03:03:17 +0000 (UTC) X-FDA: 79281412434.26.84F94A5 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf28.hostedemail.com (Postfix) with ESMTP id D80A7C003D for ; Fri, 25 Mar 2022 03:03:16 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id v2so5543715qtc.5 for ; Thu, 24 Mar 2022 20:03:16 -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=HXw7xeLeRy4CF/DJ1L3E3FO28dCYqTRXx8i65wk03SM=; b=i3tLANoBQ65aqlcXFlYzSLX4QHJwH8thr4YSc0xJn+rmAD4/12eYEQVAiAtkKdKfze cTUtDDsSOP5Lf9bfqK3clzmDl8TQ3irN4H7Gq7VuN+T7vdJODwzFKzLmsbqVJ26t5aky dchNbp6g6YKqxdvVCeVUnqw8EJnsvKx0YeP8dJcCc+WPHPmXVlAMvwVB4Z2Ctokdtu/f XqDRH51/5X2MfyFn3yUiyutjkNjKxV5O6GHCdNXemO+YzWmBoOGEnJeUAOr3rcA/cRyJ +JfrZBTtvFJ2QMZlnR888eNq2R9NnKEjJMOsB7IyiTwvVLJpNBYO2e89eBSdyJP1/G28 gwOA== 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=HXw7xeLeRy4CF/DJ1L3E3FO28dCYqTRXx8i65wk03SM=; b=b/vDPYZQeCqY0v7h/lEhM0+D8tsmChocSB7S/Gml9FP0/6YsW+Es6eVcsmaGp/UWSB Z8lNQZ+J6mFyQj6NpIqGeLUOJoaLjoujm0m7ixpX0/SNkqkugNDEmCB2a3Okzce/iR6A evs3qslusniMbYy5Wo3ubI2FZWgKJIx0UvUEpyPKbzGm77i60/6a29Tf9spzNwmbBGwj LUTgX9TC072fmln3plsjkRNH5s9zfnSq+AdnCpzZsdE2CYGtTlUmrJ6vlv6zFvvtx7zX EPoD6Cz8UN6ekDEtLlzX4jzs0k2wsMcbfCb51NcB1f7KN96BQbjtwSgxOwX9zGEa3YwZ FWRA== X-Gm-Message-State: AOAM530JXL91t3rjYXXA1MT0S+OKDt0zYyccW2YY4IoA04VCJ84qA3BJ C7AsOp1sdrgf+uScadhbcTAyYBFiKnseg8uLPBw= X-Google-Smtp-Source: ABdhPJw907iLkGFK8p2URCYxMUvLznXTHPYNJweXr/u0MpCZebXcD/6xdFnHoL4YaZ4ZwoVe8Ek8/HrqJld7ZcyopYY= X-Received: by 2002:a05:622a:1999:b0:2e2:2928:db7d with SMTP id u25-20020a05622a199900b002e22928db7dmr7588777qtc.160.1648177396226; Thu, 24 Mar 2022 20:03:16 -0700 (PDT) MIME-Version: 1.0 References: <1648113743-32622-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Fri, 25 Mar 2022 11:02:48 +0800 Message-ID: Subject: Re: [RFC PATCH] cgroup: introduce proportional protection on memcg To: Chris Down Cc: "zhaoyang.huang" , Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , ke wang , "open list:MEMORY MANAGEMENT" , LKML , cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 5ozpfchw6zp6oz6uyzius5j7kp5tmfxa Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=i3tLANoB; 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-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: D80A7C003D X-HE-Tag: 1648177396-981179 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Mar 24, 2022 at 10:27 PM Chris Down wrote: > > I'm confused by the aims of this patch. We already have proportional reclaim > for memory.min and memory.low, and memory.high is already "proportional" by its > nature to drive memory back down behind the configured threshold. > > Could you please be more clear about what you're trying to achieve and in what > way the existing proportional reclaim mechanisms are insufficient for you? What I am trying to solve is that, the memcg's protection judgment[1] is based on a set of fixed value on current design, while the real scan and reclaim number[2] is based on the proportional min/low on the real memory usage which you mentioned above. Fixed value setting has some constraints as 1. It is an experienced value based on observation, which could be inaccurate. 2. working load is various from scenarios. 3. fixed value from [1] could be against the dynamic cgroup_size in [2]. shrink_node_memcgs mem_cgroup_calculate_protection(target_memcg, memcg); \ if (mem_cgroup_below_min(memcg)) \ ===> [1] check if the memcg is protected based on fixed min/low value ... / else if (mem_cgroup_below_low(memcg)) / ... shrink_lruvec get_scan_count \ mem_cgroup_protection \ ===> [2] calculate the number of scan size proportionally scan = lruvec_size - lruvec_size * protection / (cgroup_size + 1); /