Re: [PATCH 0/2] memcg, vmpressure: expose vmpressure controls

[Leonid Moiseichuk <lmoiseichuk@magicleap.com>]

[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]

I do not agree with all comments, see below.

On Tue, Apr 14, 2020 at 3:23 PM Johannes Weiner <hannes@cmpxchg.org> wrote:

> On Tue, Apr 14, 2020 at 12:42:44PM -0400, Leonid Moiseichuk wrote:
> > On Tue, Apr 14, 2020 at 7:37 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > On Mon 13-04-20 17:57:48, svc_lmoiseichuk@magicleap.com wrote:
> > > Anyway, I have to confess I am not a big fan of this. vmpressure turned
> > > out to be a very weak interface to measure the memory pressure. Not
> only
> > > it is not numa aware which makes it unusable on many systems it also
> > > gives data way too late from the practice.
>
> Yes, it's late in the game for vmpressure, and also a bit too late for
> extensive changes in cgroup1.
>
200 lines just to move functionality from one place to another without
logic change?
There does not seem to be extensive changes.


>
> > > Btw. why don't you use /proc/pressure/memory resp. its memcg
> counterpart
> > > to measure the memory pressure in the first place?
> > >
> >
> > According to our checks PSI produced numbers only when swap enabled e.g.
> > swapless device 75% RAM utilization:
> > ==> /proc/pressure/io <==
> > some avg10=0.00 avg60=1.18 avg300=1.51 total=9642648
> > full avg10=0.00 avg60=1.11 avg300=1.47 total=9271174
> >
> > ==> /proc/pressure/memory <==
> > some avg10=0.00 avg60=0.00 avg300=0.00 total=0
> > full avg10=0.00 avg60=0.00 avg300=0.00 total=0
>
> That doesn't look right. With total=0, there couldn't have been any
> reclaim activity, which means that vmpressure couldn't have reported
> anything either.
>
Unfortunately not, vmpressure do reclaiming, I shared numbers/calls in the
parallel letter.
And I see kswapd+lmkd consumes quite a lot of cpu cycles.
That is the same device, swap disabled.
If I enable swap (zram based as Android usually does) it starts to make
some numbers below 0.1,
which does not seem huge pressure.


By the time vmpressure reports a drop in reclaim efficiency, psi
> should have already been reporting time spent doing reclaim. It
> reports a superset of the information conveyed by vmpressure.
>


> > Probably it is possible to activate PSI by introducing high IO and swap
> > enabled but that is not a typical case for mobile devices.
> >
> > With swap-enabled case memory pressure follows IO pressure with some
> > fraction i.e. memory is io/2 ... io/10 depending on pattern.
> > Light sysbench case with swap enabled
> > ==> /proc/pressure/io <==
> > some avg10=0.00 avg60=0.00 avg300=0.11 total=155383820
> > full avg10=0.00 avg60=0.00 avg300=0.05 total=100516966
> > ==> /proc/pressure/memory <==
> > some avg10=0.00 avg60=0.00 avg300=0.06 total=465916397
> > full avg10=0.00 avg60=0.00 avg300=0.00 total=368664282
> >
> > Since not all devices have zram or swap enabled it makes sense to have
> > vmpressure tuning option possible since
> > it is well used in Android and related issues are understandable.
>
> Android (since 10 afaik) uses psi to make low memory / OOM
> decisions. See the introduction of the psi poll() support:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_782662_&d=DwIBAg&c=0ia8zh_eZtQM1JEjWgVLZg&r=dIXgSomcB34epPNJ3JPl0D4WwsDd12lPHClV0_L9Aw4&m=GJC3IQZUa2vG0cqtoa4Ma_R-S_cRvQSZGbpD389b84w&s=Kp-EqrjqguJqWJ-tefwwRPeLIZennPkko0qEV_fgIbc&e=
>

Android makes a selection PSI (primary) or vmpressure (backup), see line
2872+
https://android.googlesource.com/platform/system/memory/lmkd/+/refs/heads/master/lmkd.cpp#2872


>
> It's true that with swap you may see a more gradual increase in
> pressure, whereas without swap you may go from idle to OOM much
> faster, depending on what type of memory is being allocated. But psi
> will still report it. You may just have to use poll() to get in-time
> notification like you do with vmpressure.
>
I expected that any spikes will be visible in previous avg level e.g. 10s
Cannot confirm that now but I could play around.  If you have preferences
about use-cases please let me know.


-- 
With Best Wishes,
Leonid

[-- Attachment #2: Type: text/html, Size: 6078 bytes --]