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 2F250C433F5 for ; Fri, 1 Apr 2022 01:34:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8421B6B0071; Thu, 31 Mar 2022 21:34:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F2D56B0072; Thu, 31 Mar 2022 21:34:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6915E6B0073; Thu, 31 Mar 2022 21:34:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 56A566B0071 for ; Thu, 31 Mar 2022 21:34:41 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1B3EB209E1 for ; Fri, 1 Apr 2022 01:34:31 +0000 (UTC) X-FDA: 79306590342.07.4929276 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf01.hostedemail.com (Postfix) with ESMTP id 95F6B4000B for ; Fri, 1 Apr 2022 01:34:30 +0000 (UTC) Received: by mail-qv1-f42.google.com with SMTP id gh15so967865qvb.8 for ; Thu, 31 Mar 2022 18:34:30 -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=OO61RXD1UQQlNqnQzgeVM0kWox51DdMl6bQr1525nQg=; b=p4gwZPXJ32qPFxQBPNIwc2U4bV4VVZK1GVtHoEpqp8EeXPTpe/97y8CCj+AG+Sf/yj ej3wJrClyAZ29L642a9Mts49QtN2MIUmhNqKaZ47CIgNlVIcGuFIJBoIFqGUsQD8NMf/ foB8uj4lZnc5b2yY0Lo9CfcokPcgJ84OvzuLXGUk58gws1Mn5MsL+PReCOR74hz0ryAG HaLLloFD0vxVIiySn8Fpv5K5WoPwDB2GlGP4Vnh/zovEGJjJ06eedD9f00/Limyu+SpK X51T7UekluL2AArKcmG6OPYcilTV5HPVcig62WZR18cdiSpN8uqXqgrzqM3GNQqI6uyE eTRw== 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=OO61RXD1UQQlNqnQzgeVM0kWox51DdMl6bQr1525nQg=; b=FpdnNyi+S7lQIYQp6feKErE+L4+FCSDqagn+TM9afmkbwkmvSiBnRKpk0gT8HsijHC C2gI5Nr/f1CFLIvxrrBWNGyfZJC/+/S632ydiiE1ibpROka9+Jquxe57fV9SaemabZMV varD27/WbftdwXy9GV65yHNYbXGVewdzyGUFH6D63Dw52xgye/cdrLtDSmfCCQUGwHVi 41h8IMviHIotIH7PHsJtPLrQItQrku7Xr4tAUGqNKnIOpursv52SnTey+9vus1AjiIos 1e/lrEWpstqlE7Q3z5P8X5HNukUFdf8n1YFyOKOkOb59+9NsJI2fe4fTm85bQFcXyTAR vJ4g== X-Gm-Message-State: AOAM532u8cht8N0oZzWIjNtEEPRqccIs1KdBde9D7vIGU8aOhrBySSbQ ktImbGbSr37Y3bVe1jM1uTkmzpPa1f9JrwjuBaE= X-Google-Smtp-Source: ABdhPJxbujoJAHrQsW7VFgvsWVbk3K2SMvlp7+AO426NGykoFEb7GaBtXUPMbVMay4Pvg4FhUukNnf5ZAOScLkgJ/ik= X-Received: by 2002:a05:6214:d42:b0:440:d56b:4233 with SMTP id 2-20020a0562140d4200b00440d56b4233mr6196293qvr.15.1648776869848; Thu, 31 Mar 2022 18:34:29 -0700 (PDT) MIME-Version: 1.0 References: <1648713656-24254-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Fri, 1 Apr 2022 09:34:02 +0800 Message-ID: Subject: Re: [RFC PATCH] cgroup: introduce dynamic protection for memcg To: Michal Hocko Cc: "zhaoyang.huang" , Andrew Morton , Johannes Weiner , Suren Baghdasaryan , Vladimir Davydov , "open list:MEMORY MANAGEMENT" , LKML , cgroups@vger.kernel.org, Ke Wang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 95F6B4000B X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=p4gwZPXJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-Stat-Signature: wmf9i9cyopdgtp5cr7pcbqa486zut5sy X-HE-Tag: 1648776870-484994 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 Thu, Mar 31, 2022 at 7:35 PM Michal Hocko wrote: > > On Thu 31-03-22 19:18:58, Zhaoyang Huang wrote: > > On Thu, Mar 31, 2022 at 5:01 PM Michal Hocko wrote: > > > > > > On Thu 31-03-22 16:00:56, zhaoyang.huang wrote: > > > > From: Zhaoyang Huang > > > > > > > > For some kind of memcg, the usage is varies greatly from scenarios. Such as > > > > multimedia app could have the usage range from 50MB to 500MB, which generated > > > > by loading an special algorithm into its virtual address space and make it hard > > > > to protect the expanded usage without userspace's interaction. > > > > > > Do I get it correctly that the concern you have is that you do not know > > > how much memory your workload will need because that depends on some > > > parameters? > > right. such as a camera APP will expand the usage from 50MB to 500MB > > because of launching a special function(face beauty etc need special > > algorithm) > > > > > > > Furthermore, fixed > > > > memory.low is a little bit against its role of soft protection as it will response > > > > any system's memory pressure in same way. > > > > > > Could you be more specific about this as well? > > As the camera case above, if we set memory.low as 200MB to keep the > > APP run smoothly, the system will experience high memory pressure when > > another high load APP launched simultaneously. I would like to have > > camera be reclaimed under this scenario. > > OK, so you effectivelly want to keep the memory protection when there is > a "normal" memory pressure but want to relax the protection on other > high memory utilization situations? > > How do you exactly tell a difference between a steady memory pressure > (say stream IO on the page cache) from "high load APP launched"? Should > you reduce the protection on the stram IO situation as well? We can take either system's io_wait or PSI_IO into consideration for these. > > [...] > > > One very important thing that I am missing here is the overall objective of this > > > tuning. From the above it seems that you want to (ab)use memory->low to > > > protect some portion of the charged memory and that the protection > > > shrinks over time depending on the the global PSI metrict and time. > > > But why this is a good thing? > > 'Good' means it meets my original goal of keeping the usage during a > > period of time and responding to the system's memory pressure. For an > > android like system, memory is almost forever being in a tight status > > no matter how many RAM it has. What we need from memcg is more than > > control and grouping, we need it to be more responsive to the system's > > load and could sacrifice its usage under certain criteria. > > Why existing tools/APIs are insufficient for that? You can watch for > both global and memcg memory pressure including PSI metrics and update > limits dynamically. Why is it necessary to put such a logic into the > kernel? Poll and then React method in userspace requires a polling interval and response time. Take PSI as an example, it polls ten times during POLLING_INTERVAL while just report once, which introduce latency in some extend. > > -- > Michal Hocko > SUSE Labs