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 B7197C433EF for ; Thu, 31 Mar 2022 19:26:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CC3D6B0072; Thu, 31 Mar 2022 15:26:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A3026B0073; Thu, 31 Mar 2022 15:26:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B9746B0074; Thu, 31 Mar 2022 15:26:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id F1CBF6B0072 for ; Thu, 31 Mar 2022 15:26:39 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7EACB182CCF5E for ; Thu, 31 Mar 2022 19:26:39 +0000 (UTC) X-FDA: 79305663318.30.6B0D216 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf25.hostedemail.com (Postfix) with ESMTP id 22A82A000B for ; Thu, 31 Mar 2022 19:26:38 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id t11so1182615ybi.6 for ; Thu, 31 Mar 2022 12:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TX6QX0+HXrSqPnqJDfaKnpAt/asDBfCVYhsU3t5tEcc=; b=nb3MbJRRAbBq9xDAD1NkGl6UAAGL0QIEi9Lgjrtb61uhKkmxKE2ynQ1oz3cxOJ6xaL hUw2V2U6RikzGjio0lGQsjrt8P4ZUdwVuQmENM9+qmYF4bLsKGbvRyFMp3dW2EeoZ46q Ozvbohpe3e5Et69346PFXjYvxEjxJx0h9Ow//0q/jX97jqtRytW2dgZWdpfnhKiRImgf BQXQkrxJtZNwtShSr7InkA/MggN0JtZO/Vp/58i4pvPelyqW8S2KgYer5xwnrSWNt5N2 nNQOEBZZndbQX1lmru4YUbyIp57jfGAktPoso00dg+tuqHJv2rO/pqiEAtsT976rgnoq 69NQ== 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=TX6QX0+HXrSqPnqJDfaKnpAt/asDBfCVYhsU3t5tEcc=; b=lnaEqFmOVbOxd3k1OB+h8mB4zBSCVE7X/fc/F8GMbNE2bBq4Zw+gh6y5j0XiWa06bc 7+6JiysTeo/LqIUt7WDwcNQqQJpQFZ/c81pEO+JazM88oZf9C7WYrIVxHWKU6N26CUAI u45BujUdEO5uxxcW2+5N4KgzCCfePvCFUaUrFDZvL//QOkUbKaE0crR43TMg6zSb7Xkm HTnO8erVivoiei7B1e1k1gQPLrO1VZWRZ5V33tMJ5M4MlWAhFd3FxjkWlc1S0eY/gpyg 0woQDv6xDUaA6BGOVHelc6XkSKbhjmUgTvzQYiKTXIIMI0UwqU5QBrImEPdo19+bXMWH f+IA== X-Gm-Message-State: AOAM532jUpvLVKOVP3LflNOytvaVwF0hxNXOKBqBP5vsLhZ2fFUnD5bH y9evZhLbGIwtv5+3mirL0/iU/O5LHZZkbnXVjCkrRA== X-Google-Smtp-Source: ABdhPJzb6s3dp9L52kirRHRXCjOqXWIaXLwxT6D11fIb5+efsBWozTIDW6eLFnP1mKmrG/gWXA8/BV0Ci5ZwJ4uz/Dw= X-Received: by 2002:a25:608:0:b0:634:5ff5:7c65 with SMTP id 8-20020a250608000000b006345ff57c65mr5199291ybg.282.1648754798107; Thu, 31 Mar 2022 12:26:38 -0700 (PDT) MIME-Version: 1.0 References: <1648713656-24254-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 31 Mar 2022 12:26:27 -0700 Message-ID: Subject: Re: [RFC PATCH] cgroup: introduce dynamic protection for memcg To: Michal Hocko Cc: Zhaoyang Huang , "zhaoyang.huang" , Andrew Morton , Johannes Weiner , Vladimir Davydov , "open list:MEMORY MANAGEMENT" , LKML , cgroups mailinglist , Ke Wang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 22A82A000B X-Stat-Signature: byyqrfnx3aom4uqhixq76h7j74u8rgaf X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nb3MbJRR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1648754798-401701 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 4:35 AM 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? IIUC what you are implementing here is a "memory allowance boost" feature and it seems you are implementing it entirely inside the kernel, while only userspace knows when to apply this boost (say at app launch time). This does not make sense to me. > > [...] > > > 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? I had exactly the same thought while reading through this. In Android you would probably need to implement a userspace service which would temporarily relax the memcg limits when required, monitor PSI levels and adjust the limits accordingly. > > -- > Michal Hocko > SUSE Labs