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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 88B61C2BB1D for ; Tue, 14 Apr 2020 19:23:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2D9512078A for ; Tue, 14 Apr 2020 19:23:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="RwwCmIB7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D9512078A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 987BA8E000B; Tue, 14 Apr 2020 15:23:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 910D78E0001; Tue, 14 Apr 2020 15:23:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7DBF78E000B; Tue, 14 Apr 2020 15:23:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 61B608E0001 for ; Tue, 14 Apr 2020 15:23:32 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 19486180AD801 for ; Tue, 14 Apr 2020 19:23:32 +0000 (UTC) X-FDA: 76707434664.28.bun81_1ecb003125f1e X-HE-Tag: bun81_1ecb003125f1e X-Filterd-Recvd-Size: 6097 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 19:23:31 +0000 (UTC) Received: by mail-qt1-f196.google.com with SMTP id x2so11257369qtr.0 for ; Tue, 14 Apr 2020 12:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IiZNJMCD1kbGltSbdSP42lcTPVfZZdCFmf+wp01qYTo=; b=RwwCmIB7ctPm2eZIIKDEiOKmos3jQdBxTVEG5RvZSbkV6qx3mS8owINSN9Q4vZ7OIS RV2m8pThdMF5zEvqM8E1gyAWGDKpUUtKRbX2qGs7db5dBKU+S9aWrAM7z6XMQCvIbpSV RHT+8Xv7lNrxl4dZwvcKb9a30lxz9ZqbNxtyS6EtjXe2NOPVf0EkQm45oLKdDhlO0rkz v/6G1qSst8Q0DW/UeN6I0cwt0GE7xhFcDsDyAUiLCDVa9nrQjXrKPI8lk1vvJwlt2RM5 ynB6xM183bbjPmwSl74sG2i8nCWCJ6aKUCDDLZc4WfCYXrewgkvLvBlv8vntw/Acb09x 3g9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IiZNJMCD1kbGltSbdSP42lcTPVfZZdCFmf+wp01qYTo=; b=Ib7p51zVtIspKLd/ulm/JAKYbdrCW1vMGWkPR7086xQJN7YzGxA+wh5C39KZXBoon+ OC8sc1/KK2mlI6aMnRaMJfN/VoI2/Y4ATacLMQ95kdySTjVF52p81brGnkAF4hu5Dwme rGRXylzQRSt1O0USALwcFpiF7WsiplMSsKEQDFsrOz1fu6LBxQ8e7b9dteAqv2ZPezhs TrhMATTPYhlenrUSCjziku5LHGYj2k0cgMTb17AU+bBu+lolXaJbV4lI8sEvulgEDrz6 cFQIjXNGsoR6QE8SBZNLfb+WNEg5mkvYWzvcb029RVPxpcDSFoAZwb4QUTdU4VnnDe3Z pNOQ== X-Gm-Message-State: AGi0PuaHYG/wHfiUzmHBSuoYcmGjTkdzFo6P9isg6XgsvE5JbE4R3/IP 97lFRVe44nBlMvI2z3EzXxZu4g== X-Google-Smtp-Source: APiQypIsWwXZj6Vc0/5Ixmn0EpnCIL+tbz10939EFT76GeeCqkj6YupU4aY+atQ9Pws1uWy8K2uJBQ== X-Received: by 2002:ac8:1ad1:: with SMTP id h17mr18050991qtk.9.1586892210731; Tue, 14 Apr 2020 12:23:30 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::e623]) by smtp.gmail.com with ESMTPSA id m26sm11794637qta.53.2020.04.14.12.23.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2020 12:23:30 -0700 (PDT) Date: Tue, 14 Apr 2020 15:23:29 -0400 From: Johannes Weiner To: Leonid Moiseichuk Cc: Michal Hocko , svc_lmoiseichuk@magicleap.com, 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 Subject: Re: [PATCH 0/2] memcg, vmpressure: expose vmpressure controls Message-ID: <20200414192329.GC136578@cmpxchg.org> References: <20200413215750.7239-1-lmoiseichuk@magicleap.com> <20200414113730.GH4629@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Apr 14, 2020 at 12:42:44PM -0400, Leonid Moiseichuk wrote: > 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: > > 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. > > 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. 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://lwn.net/Articles/782662/ 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.