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 B5CADC433F5 for ; Fri, 25 Mar 2022 03:08:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E1F36B0071; Thu, 24 Mar 2022 23:08:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 291BE6B0073; Thu, 24 Mar 2022 23:08:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15A936B0074; Thu, 24 Mar 2022 23:08:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id 023086B0071 for ; Thu, 24 Mar 2022 23:08:29 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8D5AE182888A0 for ; Fri, 25 Mar 2022 03:08:29 +0000 (UTC) X-FDA: 79281425538.26.85B8AD4 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf13.hostedemail.com (Postfix) with ESMTP id 256F72001E for ; Fri, 25 Mar 2022 03:08:29 +0000 (UTC) Received: by mail-qv1-f53.google.com with SMTP id k7so5277702qvc.4 for ; Thu, 24 Mar 2022 20:08:28 -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=ybNnrZFvehO2sUrmgdaOmgMmA2BO+ZMqy7l4uheBs3w=; b=d+ONl8cm9H4sIOtGkMCPjNwc/0kPC9Xeh1De38kzAoHKpgEq0pRLnhYGQQceA5GN0I iAfkjzOWFtqcqV2eaKpyGvm0FVPlAUg4/NStnrqiE1dK3ONC3OHPOAxPajhhs4NkDjkj U2WnnZtAeHRyOsQIpWVTkKuSIqq4MUsCJDqajwAOXLT3RiEeSaZpFuYuM3XLFxJ7Nk9W fDfqe+v8mWKAw0cZvTEqtUryRbLofh/weFka/Izo3auYzot6RdOcGIqEozdp1JnWtlWK DSJbQ9l3FpEw8qbR0eWFgy3J1IC2NiMJy3kCAhNp3t94C8bowwUO9yJJq+1IKPJuB9g8 M3Vw== 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=ybNnrZFvehO2sUrmgdaOmgMmA2BO+ZMqy7l4uheBs3w=; b=HPhEvuVVpRkmfew3jg7gg6otJbBFFvj7YU2X2ZWLJtNR1LnsAkjX0so/ZX/ng4Cg3g YSGhc43SJIsR3jJ0i9Jx9X4/tfr/m3bRosOeN+hA59JsU8DTiuyP5JK7QR7RbHQjeojn KvHyC/DfLcAb2WDbW6u1NqJFEFcv+TIjf9w4Qx3ELTKag/BApLPjHu4PFiNHtaoxkajy AVw22UaKrxdHobuhYbyBs2ZjY+7PfD3sueC1IQMOSn77tzrzSMIY/HW17pP9GDcSN/mQ xWnoHUEskoeGJTqadh+U5CzMVQpYY0ZvXw7riQOG4lEhDNBBNUOeIyccJbeEfqWp/UQ+ Hjag== X-Gm-Message-State: AOAM533MeTJmjQc3UJEmOCEq0/3AArzZEb4Km6B4hcFqowx1qW6PR0ee saLfsxafC079y5ubn9uKU9UEq9W86bGQvbNJSCE= X-Google-Smtp-Source: ABdhPJxsnPOesyWogaWyVJTt4mMq8tJelTDADS1Yx8hNRsCJLvPjsPVLoTW5e5D6Om/xI8Z2C/jvzamoPYNJudFS8ng= X-Received: by 2002:a05:6214:2522:b0:441:404e:7317 with SMTP id gg2-20020a056214252200b00441404e7317mr6966072qvb.77.1648177708580; Thu, 24 Mar 2022 20:08:28 -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:08:00 +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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 256F72001E X-Stat-Signature: t5zyg4g8wx4fhhaxzg6m1qua1kabrj1s Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=d+ONl8cm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Rspam-User: X-HE-Tag: 1648177709-540772 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 Fri, Mar 25, 2022 at 11:02 AM Zhaoyang Huang wrote: > > 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? sorry for the bad formatting of previous reply, resend it in new format 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 [1] check if the memcg is protected based on fixed min/low value mem_cgroup_calculate_protection(target_memcg, memcg); if (mem_cgroup_below_min(memcg)) ... else if (mem_cgroup_below_low(memcg)) ... [2] calculate the number of scan size proportionally shrink_lruvec get_scan_count mem_cgroup_protection scan = lruvec_size - lruvec_size * protection / (cgroup_size + 1);