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 34C79C2BA19 for ; Wed, 15 Apr 2020 12:33:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC8562074F for ; Wed, 15 Apr 2020 12:33:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=magicleap.com header.i=@magicleap.com header.b="Wj1WQpPE"; dkim=pass (1024-bit key) header.d=magicleap.com header.i=@magicleap.com header.b="SZplFvFU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC8562074F 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 720308E0018; Wed, 15 Apr 2020 08:33:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AA888E0001; Wed, 15 Apr 2020 08:33:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5720B8E0018; Wed, 15 Apr 2020 08:33:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id 3F8828E0001 for ; Wed, 15 Apr 2020 08:33:25 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id ED83B181AEF21 for ; Wed, 15 Apr 2020 12:33:24 +0000 (UTC) X-FDA: 76710029928.09.shame05_a915be26947 X-HE-Tag: shame05_a915be26947 X-Filterd-Recvd-Size: 9663 Received: from mx0b-001e9b01.pphosted.com (mx0b-001e9b01.pphosted.com [148.163.159.123]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Apr 2020 12:33:24 +0000 (UTC) Received: from pps.filterd (m0176109.ppops.net [127.0.0.1]) by mx0b-001e9b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03FCH17Q001779 for ; Wed, 15 Apr 2020 08:33:23 -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=qXbQ+Qm/Gac+TyEks/4rLTkvZuVLQQ64FCM2aNN2MEY=; b=Wj1WQpPE1JqfbXEGxWo7/AHJbX2ux7QQpv/rJbyHfq9DPjya476esJJbcf6DcW8Gi6vt hxRTYxCQv1bwjjl9TxLEx5x7ej0U0Vurs+wFtK9870SDZS3gbyKpQKr96+4p4aZXjV5I CQbLnMxl44QDnrKml1Rqn39v0r4a9N/Bvq1wubzHBYZsKlzpH5B4fOh/+3fJs9aWFxkL 9eVgicwAG01BrAPedM8T5JLNxiX62l5njsEB7b/07YcSXforXO6HUvD/XKPCgXwY/78a CvXZ6NWD/lkLA8LbOpqwfCbRm/ctovCAJDMvSgLdBqc1czai2Gzi04B667ujJQND3E/R Aw== Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by mx0b-001e9b01.pphosted.com with ESMTP id 30dn9prhrs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 15 Apr 2020 08:33:13 -0400 Received: by mail-qv1-f69.google.com with SMTP id m20so2803577qvy.13 for ; Wed, 15 Apr 2020 05:33:13 -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=qXbQ+Qm/Gac+TyEks/4rLTkvZuVLQQ64FCM2aNN2MEY=; b=SZplFvFUSugoxpjIKrQ3L6WPRfDw0kVFZMPeG/QhOz/FOamQLDQyKAltBLlz7w1D2o fuot7aejWpJ+N7y6noVcFXdtbNU8mU+SXkVkZBclLiwFM3Pkt3gANpdSmT+6nDZLIeTW p1agWWfC/BjgR5V8/NxqhVJpUNCYWWRZFnDPU= 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=qXbQ+Qm/Gac+TyEks/4rLTkvZuVLQQ64FCM2aNN2MEY=; b=lq17KC6q9YnHFj/wW5I54/jKcapv+6oH73rV/Ck5PEA9o1pMOYqe7DRzAy9JStebit exMacU7BNmX/v7LDHa4E03WUvVAGtVK9ifo7gGXYdZOEXZbkOA8UjmsKYbyGMykUt57K hyJts7Q6F1su5BqjXKFXQIgpshjqmFUYRbN3i8Nau2rbSc+87YeM/3+OvtATJ9+hbeIV 8lfvM3imao7GF5oN6Ismw0MU/n0wm6NWdUX6lXrZ31pubgZIoO2x0yjpFE0OfcHDF8e5 8bTanVYuKUDugJyijD+xrr3ytNQ8tMOrgvLAORXk+zedNHkiDkLphiWdAyaRn469ydQQ sQ0w== X-Gm-Message-State: AGi0PuZgOmkkliAAWjOfZsOuBYMw9Nbe4BwN2tw7uXpn5jWCb7mknd6p sNYDjOql2bFsW0BtFX49bKlKrvQSkiwuFmrITij7SKMT4DIrfaJya2UjHAsvkz2Y3EaPJKUaifs 5+APjA7sOhpinWCGLXw0l0L/2D54= X-Received: by 2002:a0c:fdc3:: with SMTP id g3mr4753477qvs.184.1586953992919; Wed, 15 Apr 2020 05:33:12 -0700 (PDT) X-Google-Smtp-Source: APiQypKzuQQbG4DAfPluS89xPduRGWJwwC0E+viEaUATEswTGLEDh6X158MniRbAV7Hz9uaM0AI1oS4EhtOajhBacxk= X-Received: by 2002:a0c:fdc3:: with SMTP id g3mr4753450qvs.184.1586953992699; Wed, 15 Apr 2020 05:33:12 -0700 (PDT) MIME-Version: 1.0 References: <20200413215750.7239-1-lmoiseichuk@magicleap.com> <20200414113730.GH4629@dhcp22.suse.cz> <20200414184917.GT4629@dhcp22.suse.cz> <20200415075136.GY4629@dhcp22.suse.cz> <20200415122857.GL4629@dhcp22.suse.cz> In-Reply-To: <20200415122857.GL4629@dhcp22.suse.cz> From: Leonid Moiseichuk Date: Wed, 15 Apr 2020 08:33:01 -0400 Message-ID: Subject: Re: [PATCH 0/2] memcg, vmpressure: expose vmpressure controls To: Michal Hocko Cc: svc lmoiseichuk , Johannes Weiner , 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, penberg@kernel.org, linux-mm@kvack.org Content-Type: multipart/alternative; boundary="00000000000002a16e05a3538527" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676 definitions=2020-04-15_03:2020-04-14,2020-04-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 adultscore=0 phishscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 suspectscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004150093 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: --00000000000002a16e05a3538527 Content-Type: text/plain; charset="UTF-8" Good point but at the current moment I am not ready to implement autotune window size because my device only has 8 GB RAM and a very custom version of Android-based SW. So basically I cannot test in all possible combinations. On Wed, Apr 15, 2020 at 8:29 AM Michal Hocko wrote: > On Wed 15-04-20 08:17:42, Leonid Moiseichuk wrote: > > As Chris Down stated cgroups v1 frozen, so no API changes in the mainline > > kernel. > > Yes, this is true, _but_ if there are clear shortcomings in the existing > vmpressure implementation which could be addressed reasonably then there > is no reason to ignore them. > > [...] > > > > I still find this very confusing because the amount of used memory is > > > not really important. It really only depends on the reclaim activity > and > > > that is either the memcg or the global reclaim. And you are getting > > > critical levels only if the reclaim is failing to reclaim way too many > > > pages. > > > > > > > OK, agree from that point of view. > > But for larger systems reclaiming happens not so often and we can > > use larger window sizes to have better memory utilization approximation. > > Nobody is saying the the window size has to be fixed. This all can be > auto tuned in the kernel. It would, however, require to define what > "better utilization approximation" means much more specifically. > > [...] > > > This looks more like a problem of vmpressure implementation than > > > something you want to workaround by tuning to me. > > > > > Basically it is how it works - collect the scanned page and activate > worker > > activity to update the current level. > > That is the case only for some vmpressure invocations. And your data > suggest that those might lead to misleading results. So this is likely > good to focus on and find out whether this can be addressed. > -- > Michal Hocko > SUSE Labs > -- With Best Wishes, Leonid --00000000000002a16e05a3538527 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good point but at the current moment I am not ready to imp= lement autotune window size because my device only has 8 GB RAM and a very = custom version of Android-based SW.
So=C2=A0 basically I cannot test in= all possible combinations.

On Wed, Apr 15, 2020 at 8:29 AM Michal Hoc= ko <mhocko@kernel.org> wrote= :
On Wed 15-04-2= 0 08:17:42, Leonid Moiseichuk wrote:
> As Chris Down stated cgroups v1 frozen, so no API changes in the mainl= ine
> kernel.

Yes, this is true, _but_ if there are clear shortcomings in the existing vmpressure implementation which could be addressed reasonably then there is no reason to ignore them.

[...]

> > I still find this very confusing because the amount of used memor= y is
> > not really important. It really only depends on the reclaim activ= ity and
> > that is either the memcg or the global reclaim. And you are getti= ng
> > critical levels only if the reclaim is failing to reclaim way too= many
> > pages.
> >
>
> OK, agree from that point of view.
> But for larger systems reclaiming happens not so often and we can
> use larger window sizes to have better memory utilization approximatio= n.

Nobody is saying the the window size has to be fixed. This all can be
auto tuned in the kernel.=C2=A0 It would, however, require to define what "better utilization approximation" means much more specifically.<= br>
[...]
> > This looks more like a problem of vmpressure implementation than<= br> > > something you want to workaround by tuning to me.
> >
> Basically it is how it works - collect the scanned page and activate w= orker
> activity to update the current level.

That is the case only for some vmpressure invocations. And your data
suggest that those might lead to misleading results. So this is likely
good to focus on and find out whether this can be addressed.
--
Michal Hocko
SUSE Labs


--
With Best Wishes,
Leonid
--00000000000002a16e05a3538527--