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 X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56421C2BA19 for ; Tue, 14 Apr 2020 18:16:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F0BC720774 for ; Tue, 14 Apr 2020 18:16:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=magicleap.com header.i=@magicleap.com header.b="DKCGkmIn"; dkim=pass (1024-bit key) header.d=magicleap.com header.i=@magicleap.com header.b="O7LhufJ8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0BC720774 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=magicleap.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7217D8E0011; Tue, 14 Apr 2020 14:16:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D35A8E0001; Tue, 14 Apr 2020 14:16:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C3028E0011; Tue, 14 Apr 2020 14:16:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 458438E0001 for ; Tue, 14 Apr 2020 14:16:36 -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 04678180AD807 for ; Tue, 14 Apr 2020 18:16:36 +0000 (UTC) X-FDA: 76707265992.30.waste47_1c6b5853cc104 X-HE-Tag: waste47_1c6b5853cc104 X-Filterd-Recvd-Size: 15096 Received: from mx0a-001e9b01.pphosted.com (mx0a-001e9b01.pphosted.com [148.163.157.123]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 18:16:35 +0000 (UTC) Received: from pps.filterd (m0176108.ppops.net [127.0.0.1]) by mx0a-001e9b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03EI9Xht017594 for ; Tue, 14 Apr 2020 14:16:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=magicleap.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pp09042018; bh=JEZHMW0LJOmMPI/sZyOU/K9undYao5aPEvcO43lhJ54=; b=DKCGkmInPpWN/NNejCgiQeoPr1ECjcYfOZYbu2v4Y43A/teFAHHf6rVhXjcqs62aW2aE UTWPemUbNy+pKFnhksMpHiGF0I73hd+wdQNLC/OJhY/Q4NuWY+AeCvxB2r/Eq15XJaaf c+27rpg/vNxf5zs586QpQWp2XnvLkYf5zuzn3VWwqvqRt6BX7LwBoFkrd8EhbbJcqEVf udMLSH+iXu1ORbrwUGB0vFoekeWEJ+NJDacmZHOgebe+M2KXYzd0CqhWhUid0cGUDdqe 8N2zd/lyTbm2WDvGpVEbZFCvsF9h1XXeZSwLL0dtVoCy9OmfXD0ZixXqXGzULOPfxpoH TQ== Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by mx0a-001e9b01.pphosted.com with ESMTP id 30b7xqjr12-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 14 Apr 2020 14:16:33 -0400 Received: by mail-io1-f70.google.com with SMTP id c26so10515025ioa.4 for ; Tue, 14 Apr 2020 11:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=magicleap.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JEZHMW0LJOmMPI/sZyOU/K9undYao5aPEvcO43lhJ54=; b=O7LhufJ8l7BDG/4/VhXIiliX7aPm5+pxxu+aKQc8cq4BDpLZFAg9gAYD3ydOAQRXBF +PZApm6eVjD3GiHEalJxB5uHrn+ZKrU65w5dCd0hjdlXsI0hjaYMXhlQlbIopPmFin46 e6x6raMxmktI5AwP8PcLFf0UPo5UUm7qc+324= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JEZHMW0LJOmMPI/sZyOU/K9undYao5aPEvcO43lhJ54=; b=nAGVILpmMuPs9DK8tJUmslcoOa3LYoHy8TyrT53qeRYVmeHn5ijuWHFNYs7NAbRiwp 88l1Uf0PTthScjCNJ/fWTskRBT0YrJfrksLMl4N9vBmNnKoCJbDqoXXKbBqTTGJ3EtWA +n4TcBLv/GvEsvFcAWwzs2NEwOlDXgihpAeQPM1BWucmKhwDHg27QvNwslpxFO6tdjZ+ WW357c5fDlebT0+M2QXpuz0Z6oulnaoWRIvzTIp0DR+iqgjycZogt6ehVOoRI6oSUmnu zWP6G0/Orty0ndVe4szKIjCBNB2P/HVaYaEWqi5cN9SzoRBiB5Q2GB4Hu5zgUb0gFotR emZQ== X-Gm-Message-State: AGi0Pubw/sH00p2SEKo5lI+6mGS3v0Tg8lzOkM7vDmsdycVwAVgGBzn4 xXNjl+YwAvQDFbRpS6KTq8gUrDunWfZmF3zpfahn9LDOSCsgNcG/xHSAsuHviQZOZvMy0YZa2xy Wy+9b/Ell5oTEH/iA6MtGWqvzKls= X-Received: by 2002:aed:37a8:: with SMTP id j37mr17275730qtb.272.1586882576312; Tue, 14 Apr 2020 09:42:56 -0700 (PDT) X-Google-Smtp-Source: APiQypKiet46EepoNIUeoauQNUeV/UPrG9hoGt2fsV9S3FcBPEJK5SrHdhjz6TJZ5ETjG9qkA45CpDRqGNDZjfI2+dw= X-Received: by 2002:aed:37a8:: with SMTP id j37mr17275701qtb.272.1586882575951; Tue, 14 Apr 2020 09:42:55 -0700 (PDT) MIME-Version: 1.0 References: <20200413215750.7239-1-lmoiseichuk@magicleap.com> <20200414113730.GH4629@dhcp22.suse.cz> In-Reply-To: <20200414113730.GH4629@dhcp22.suse.cz> From: Leonid Moiseichuk Date: Tue, 14 Apr 2020 12:42:44 -0400 Message-ID: Subject: Re: [PATCH 0/2] memcg, vmpressure: expose vmpressure controls To: Michal Hocko Cc: svc_lmoiseichuk@magicleap.com, hannes@cmpxchg.org, vdavydov.dev@gmail.com, tj@kernel.org, lizefan@huawei.com, cgroups@vger.kernel.org, akpm@linux-foundation.org, rientjes@google.com, minchan@kernel.org, vinmenon@codeaurora.org, andriy.shevchenko@linux.intel.com, anton.vorontsov@linaro.org, penberg@kernel.org, linux-mm@kvack.org Content-Type: multipart/alternative; boundary="0000000000003d80c305a342e4a4" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-04-14_09:2020-04-14,2020-04-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 suspectscore=5 clxscore=1011 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004140131 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: --0000000000003d80c305a342e4a4 Content-Type: text/plain; charset="UTF-8" Thanks Michal for quick response, see my answer below. I will update the commit message with numbers for 8 GB memory swapless devices. On Tue, Apr 14, 2020 at 7:37 AM Michal Hocko wrote: > On Mon 13-04-20 17:57:48, svc_lmoiseichuk@magicleap.com wrote: > > From: Leonid Moiseichuk > > > > Small tweak to populate vmpressure parameters to userspace without > > any built-in logic change. > > > > The vmpressure is used actively (e.g. on Android) to track mm stress. > > vmpressure parameters selected empiricaly quite long time ago and not > > always suitable for modern memory configurations. > > This needs much more details. Why it is not suitable? What are usual > numbers you need to set up to work properly? Why those wouldn't be > generally applicable? > As far I see numbers which vmpressure uses - they are closer to RSS of userspace processes for memory utilization. Default calibration in memory.pressure_level_medium as 60% makes 8GB device hit memory threshold when RSS utilization reaches ~5 GB and that is a bit too early, I observe it happened immediately after boot. Reasonable level should be in the 70-80% range depending on SW preloaded on your device. >From another point of view having a memory.pressure_level_critical set to 95% may never happen as it comes to a level where an OOM killer already starts to kill processes, and in some cases it is even worse than the now removed Android low memory killer. For such cases has sense to shift the threshold down to 85-90% to have device reliably handling low memory situations and not rely only on oom_score_adj hints. Next important parameter for tweaking is memory.pressure_window which has the sense to increase twice to reduce the number of activations of userspace to save some power by reducing sensitivity. For 12 and 16 GB devices the situation will be similar but worse, based on fact in current settings they will hit medium memory usage when ~5 or 6.5 GB memory will be still free. > > 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. > > 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 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. > > Leonid Moiseichuk (2): > > memcg: expose vmpressure knobs > > memcg, vmpressure: expose vmpressure controls > > > > .../admin-guide/cgroup-v1/memory.rst | 12 +- > > include/linux/vmpressure.h | 35 ++++++ > > mm/memcontrol.c | 113 ++++++++++++++++++ > > mm/vmpressure.c | 101 +++++++--------- > > 4 files changed, 200 insertions(+), 61 deletions(-) > > > > -- > > 2.17.1 > > > > -- > Michal Hocko > SUSE Labs > -- With Best Wishes, Leonid --0000000000003d80c305a342e4a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Michal for quick response, see my answer=C2=A0= below.
I will update the commit message with numbers for 8 GB mem= ory swapless devices.

On Tue, Apr 14, 2020 at 7:37 AM Michal Hocko <mhocko@kernel.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Mon 13-04-20 17:57:48, = svc_lmoi= seichuk@magicleap.com wrote:
> From: Leonid Moiseichuk <lmoiseichuk@magicleap.com>
>
> Small tweak to populate vmpressure parameters to userspace without
> any built-in logic change.
>
> The vmpressure is used actively (e.g. on Android) to track mm stress.<= br> > vmpressure parameters selected empiricaly quite long time ago and not<= br> > always suitable for modern memory configurations.

This needs much more details. Why it is not suitable? What are usual
numbers you need to set up to work properly? Why those wouldn't be
generally applicable?
As far I see numbers which vmpre= ssure uses - they are closer to RSS of userspace processes for memory utili= zation.
Default calibration in=C2=A0memory.pressure_level_medium = as 60% makes 8GB device hit memory threshold when RSS utilization=C2=A0
reaches ~5 GB and that is a bit too early, I observe it happened imm= ediately after boot. Reasonable level should be=C2=A0
in the 70-8= 0% range depending on SW preloaded on your device.

>From another point of view having a=C2=A0memory.pressure_level_critical se= t to 95% may never happen as it comes to a level where an OOM killer alread= y starts to kill processes,
and in some cases it is even wors= e than the now removed Android low memory killer. For such cases has sense = to shift the threshold down to 85-90% to have device reliably
han= dling low memory situations and not rely only on oom_score_adj hints.
=

Next important parameter for tweaking is=C2=A0memory.pr= essure_window which has the sense to increase twice to reduce the number of= activations of userspace
to save some power by=C2=A0reducing sen= sitivity.

For 12 and 16 GB devices the situation w= ill be similar but worse, based on fact in current settings they will hit m= edium memory usage when ~5 or 6.5 GB memory will be still free.
= =C2=A0

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.

Btw. why don't you use /proc/pressure/memory resp. its memcg counterpar= t
to measure the memory pressure in the first place?
According to our checks PSI produced numbers only when swap ena= bled e.g. swapless device 75% RAM utilization:
=3D=3D> /proc/p= ressure/io <=3D=3D
some avg10=3D0.00 avg60=3D1.18 avg300= =3D1.51 total=3D9642648
full avg10=3D0.00 avg60=3D1.11 avg300=3D1.47 tot= al=3D9271174

=3D=3D> /proc/pressure/memory <=3D=3D
some avg= 10=3D0.00 avg60=3D0.00 avg300=3D0.00 total=3D0
full avg10=3D0.00 avg60= =3D0.00 avg300=3D0.00 total=3D0

Probably=C2=A0= 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 fract= ion i.e. memory is io/2 ... io/10 depending on pattern.
Light sys= bench case with swap enabled
=3D=3D> /proc/pressure/io <=3D= =3D
some avg10=3D0.00 avg60=3D0.00 avg300=3D0.11 total=3D1553= 83820
full avg10=3D0.00 avg60=3D0.00 avg300=3D0.05 total=3D100516966
=3D=3D> /proc/pressure/memory <=3D=3D
some avg10=3D0.00 avg= 60=3D0.00 avg300=3D0.06 total=3D465916397
full avg10=3D0.00 avg60=3D0.00= avg300=3D0.00 total=3D368664282

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 iss= ues are understandable.


> Leonid Moiseichuk (2):
>=C2=A0 =C2=A0memcg: expose vmpressure knobs
>=C2=A0 =C2=A0memcg, vmpressure: expose vmpressure controls
>
>=C2=A0 .../admin-guide/cgroup-v1/memory.rst=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 12 +-
>=C2=A0 include/linux/vmpressure.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 35 ++++++
>=C2=A0 mm/memcontrol.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 113 +++++++= +++++++++++
>=C2=A0 mm/vmpressure.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 101 +++++++= ---------
>=C2=A0 4 files changed, 200 insertions(+), 61 deletions(-)
>
> --
> 2.17.1
>

--
Michal Hocko
SUSE Labs


--
With Best Wishes,
Leonid
--0000000000003d80c305a342e4a4--