Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2190944pxb; Fri, 25 Mar 2022 12:43:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqwNT8R1sZvmYz4Y95Z6ODr3qL2MfwqC4uNe7ZOuOfwZr0rbsdTNzHHX2oxClxbW8FiP4Y X-Received: by 2002:a05:6a02:101:b0:386:865:44a0 with SMTP id bg1-20020a056a02010100b00386086544a0mr889752pgb.475.1648237411246; Fri, 25 Mar 2022 12:43:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648237411; cv=none; d=google.com; s=arc-20160816; b=hwzA3VWeNccwoKUlk+XBzk+3ROfzCIvSqfL19BqIl88BW+AcZTXjOjIs87/kTRfiBX YKv9MMhUhKaDQjWmYYI8IHmBtBzxGEhbOaLzgwvsiK6Gpaf7H4DR6flFsK3BTZ26dnzK nArXqlW9r/Fb46upHkNpUS4B/vVS7diZroQI+VkkvYzAzltfhf2ebkQsCgptEm9xEe8z CJuAkgZ2gWFyDnUmR5YSpc0wVj6AtWvvW2oYxXoyIiQt0/MBpZnA59WrRVckG2XcaubT PWqN62f0se3l8+aEsrrv55Ja47lMxYQ3Be3DB1CknGPMvhueZWgf3ypTRHvXKp6Xsmuq TzgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=HXw7xeLeRy4CF/DJ1L3E3FO28dCYqTRXx8i65wk03SM=; b=k5bnKdGBUgkeiFV/gH1fijxwRoCfKIr6di9nuKQA+5H5UFJNlG5ZTI2Py0S+iQCJji ZnKzMFcDpROmImjn5VAc8muIb7qoehWKRireeoPH0cwaZH2YxUqscQAQWPrxW+WvaaA7 EANqPo4im06uj30kovrQkJlx6+2AZz1325vs/hasITiEJvJZ9gg9VEEO89JE5BabWuED zNAgRLU7XsQj45I+FaecjCn0aCXDb+QOpicjJ6dIA2IS6ICEEPNtQgjbmfbZdhPdjUdm SIvDflRkDToc3ysZSsS7xWxl9JVtBjeGb2curnJYE78TEKrDaN65cD/JeQ+zoCmeaCbz 1+/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=i3tLANoB; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id v18-20020a63ac12000000b003816043ef37si3263276pge.300.2022.03.25.12.43.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 12:43:31 -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=@gmail.com header.s=20210112 header.b=i3tLANoB; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7D8D518A3DE; Fri, 25 Mar 2022 11:34:04 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354845AbiCYDE6 (ORCPT + 99 others); Thu, 24 Mar 2022 23:04:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346585AbiCYDEu (ORCPT ); Thu, 24 Mar 2022 23:04:50 -0400 Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1260E11C2B; Thu, 24 Mar 2022 20:03:17 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id t7so5531321qta.10; Thu, 24 Mar 2022 20:03:17 -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=WgfjzVgNPbxC+fpwIzRme7umT7d7SWgxw1d+fsbmSJNeyMFgj+S1EZtQs1sciS5qmk qm3gw8iP3T1noZ9PUJKANefUKV/ggYL/AfxWPorKCxObEVrHuskTy75GjKrL8rEjpVLP wDiLyNgTRRPe3hpa/cgahD9ihUHJfITz5CzMN8ZEK9Sgf6Gb/7uN591B3gKJUuiPM3UQ ALTnQTHy4/0iBCHuhLl1ual+8756E8mhJnuT6iWbK0YRO2/JgzDUDci/HPEnhCZChozs TGp07qcffg/BIoCcRsdJpoA+p4tppCArDK4dvlL+xRmirqhnuClG+g/4F1NI9GS5Uw1A vUYA== X-Gm-Message-State: AOAM532L4+KvX80ZduwtKxA9VAA1FyW5jZGpIfvWY6vIz6mkyaYb5YA0 ivCNDUEauzV3oLyxcEiY4DzvKJmqROb58apZ7HCl8C5yLZMWQA== 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-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 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); /