lkml.org 
[lkml]   [2022]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH] cgroup: introduce dynamic protection for memcg
    On Thu 31-03-22 19:18:58, Zhaoyang Huang wrote:
    > On Thu, Mar 31, 2022 at 5:01 PM Michal Hocko <mhocko@suse.com> wrote:
    > >
    > > On Thu 31-03-22 16:00:56, zhaoyang.huang wrote:
    > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
    > > >
    > > > 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?

    [...]
    > > 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?

    --
    Michal Hocko
    SUSE Labs

    \
     
     \ /
      Last update: 2022-03-31 13:36    [W:2.273 / U:0.796 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site