Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp56253rwb; Wed, 18 Jan 2023 14:04:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXtNeSPxRmZ2LuD2Tut6X2qrvgfsNzwLUpS/MbOGC7N7NUW2+ozB8H0yKvtRresParRJT6L8 X-Received: by 2002:a17:906:8d86:b0:870:dceb:696d with SMTP id ry6-20020a1709068d8600b00870dceb696dmr14019816ejc.43.1674079495732; Wed, 18 Jan 2023 14:04:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674079495; cv=none; d=google.com; s=arc-20160816; b=TrAjtVcnqsyOnPX7KpZj36ytpweo1caWjZAVdZLgZPjBuu1vnOr/WJk4nZzmzGo7+l kbSs5Qtk3xXVdBamGBT1yeefKlqcVtR3YbdhOM6/wx1avkH4OWf3FHyLJx0YYAKfp7Li CqclpikEeZn8ArtiBiX9Xv7WRg8ZTgA2OJzd3Gl77qiE600v5yzyBB8+4ah9R1LgJwFm 3Nrul1cK2Pb6IQXEZvPA7ax57ymMQ6Oy6uJ/iYxb+yyZQKeFyIeLy0EhRqd138++Nz/y 1Bj9KiNkELmzV+EWsDcw2Pw9qXxapAT0dQpKITB0Fwt4jIYkEoNeKByq1p7m6B53N8np 9aCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=ffnkh4zmysw3vaXwpundCOoVmU47s9oaVyFRyCfZsPw=; b=TIrw0ys8rR8lr4JpuSpH9iQHMVmm+FmF+bVYnDQljDCxIrY+bUatU8TVqjVwnnNSsX h2aW8UVzaVQRdUeGcYb0fBqC2asP7GGFbZAmk8oFv8oWOOeFBYcTYrfWtLqpqiT699PZ wsS1eZSvIS6lncAwJlrxwjCQdAUEI/MDVL4nPm+6Yd76/HLpweWLcTM51UkkkggmhENX zMWAadvGZJ7/ew/HOUmfZhwPNifN09LILEkxeBpxaZbcKsc95Vn+Z44Itdd7eNL/EhQ8 JLjO7Ml/0UWQc8WyNA/+kkZN+7t3DVsFXH7idfxg9RrRs+k+M7sxzr1iDnhJXMsyzAIg 7i4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Wvx839aS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y8-20020a50eb08000000b0048eaa94efafsi15683197edp.197.2023.01.18.14.04.42; Wed, 18 Jan 2023 14:04:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Wvx839aS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231271AbjARVrb (ORCPT + 45 others); Wed, 18 Jan 2023 16:47:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231284AbjARVr3 (ORCPT ); Wed, 18 Jan 2023 16:47:29 -0500 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D06A462D10 for ; Wed, 18 Jan 2023 13:47:27 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id k13so487596plg.0 for ; Wed, 18 Jan 2023 13:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=ffnkh4zmysw3vaXwpundCOoVmU47s9oaVyFRyCfZsPw=; b=Wvx839aSwuI8Akay3jFqTCUbMYQXrzZ0twFxcZq5OZMmj9QiJAOPRVAVOMjWKKm35l kYQwsTUdFRiyHa34M5GGH8p2Es5sWJkSb/YJ+zFs2d9xhPOw70ad6rhDPgA/0x27fJAy prg4jDTGDVpXsve/C416mYRvkZ0CBdgiy7BVkhTpXCWiCR2dd3sBCQCxpYIBEiClc6Ro lCic12AY4qkwZPcdfnJjJGfsjsF51eLXjp3OdIqGYC1ytCXM7G+ol4z2jDQI1SNCKGyn i3axNccfjuqK7hg9EC/kswxTbaW8WSiXY9Qa6MSmb4zCj0mmVWY0tN8SM4hl8/C5cgCt Xbhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ffnkh4zmysw3vaXwpundCOoVmU47s9oaVyFRyCfZsPw=; b=j9RIM+HuJf5QBY2MO6htwDO8lo0O5AoikAHHymmsIIdInxqQlawgIAC+VXBdv+y/Kp oOi3jCAz/9IjdLLGe8u7nSUJnDF2VR5rx6Zk+G85nC0cCt6UWvwj+PQ2ePhOZlP10Ury n1k70bCtEMZ+xHvEbl5cuzNSK/7sInoyTRzUW6lPugK2VLkbKH+vzuh0On7rRloeytXO 5Nw6QqPWFdoDKwbiXn/umK9Q+45vZaaJ18Nh1cJ17W3M0bFx7sPln+ex0ET/eAbWG/Kn SsT2yphOuXVgepaEUD9n0yh3ZF4mfoJJtvABdzcge7Ag0z5DdXsR4f+ncqq8FFXs1YR2 dNEg== X-Gm-Message-State: AFqh2kqnCUvzJzsdojrAv6jMS0uM90/EI8XqnTBuXnyEW+3l7A8Ui3Kf 3XhmNgA1DlKUHAlRvN0c43I= X-Received: by 2002:a17:902:b091:b0:194:8261:8018 with SMTP id p17-20020a170902b09100b0019482618018mr8556580plr.64.1674078447265; Wed, 18 Jan 2023 13:47:27 -0800 (PST) Received: from google.com ([2620:15c:211:201:68ba:bd93:858:15d5]) by smtp.gmail.com with ESMTPSA id s19-20020a170902a51300b001949b92f8a8sm5626063plq.279.2023.01.18.13.47.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 13:47:26 -0800 (PST) Sender: Minchan Kim Date: Wed, 18 Jan 2023 13:47:24 -0800 From: Minchan Kim To: Michal Hocko Cc: Andrew Morton , Suren Baghdasaryan , Matthew Wilcox , linux-mm , LKML , SeongJae Park Subject: Re: [PATCH 3/3] mm: add vmstat statistics for madvise_[cold|pageout] Message-ID: References: <20230117231632.2734737-1-minchan@kernel.org> <20230117231632.2734737-3-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 18, 2023 at 10:13:38PM +0100, Michal Hocko wrote: > On Wed 18-01-23 09:55:38, Minchan Kim wrote: > > On Wed, Jan 18, 2023 at 06:27:02PM +0100, Michal Hocko wrote: > > > On Wed 18-01-23 09:15:34, Minchan Kim wrote: > > > > On Wed, Jan 18, 2023 at 10:11:46AM +0100, Michal Hocko wrote: > > > > > On Tue 17-01-23 15:16:32, Minchan Kim wrote: > > > > > > madvise LRU manipulation APIs need to scan address ranges to find > > > > > > present pages at page table and provides advice hints for them. > > > > > > > > > > > > Likewise pg[scan/steal] count on vmstat, madvise_pg[scanned/hinted] > > > > > > shows the proactive reclaim efficiency so this patch addes those > > > > > > two statistics in vmstat. > > > > > > > > > > Please describe the usecase for those new counters. > > > > > > > > I wanted to know the proactive reclaim efficieny using MADV_COLD/MDDV_PAGEOUT. > > > > Userspace has several policy which when/which vmas need to be hinted by the call > > > > and they are evolving. I needed to know how effectively their policy works since > > > > the vma ranges are huge(i.e., nr_hinted/nr_scanned). > > > > > > I can see how that can be an interesting information but is there > > > anything actionable about that beyond debugging purposes? In other words > > > isn't this something that could be done by tracing instead? > > > > That's the statictis for telemetry. With those stat, we are collecting > > various vmstat fields(i.e., pgsteal/pgscan) from real field devices > > and thought those two stats would be good fit along with other reclaim > > statistics in vmstat since we can know how much proactive madvise policy > > could make system healthier(e.g., less kswapd scan, less allocstall > > and so on). > > > > > > > > Also how are you going to identify specific madvise calls when they can > > > interleave arbitrarily? > > > > I guess you are talking about how we could separate MADV_PAGEOUT and > > MADV_COLD from vmstat. That's valid question. I thought for the start, > > adds just umbrella stat like this and if we want to break down, we need > > to introudce sysfs likewise slab. > > No, not really. MADV_COLD is about aging. There is no actual reclaim > going on so pgscan/steal metrics do not make any sense. I am asking > about potential different concurrent MADV_PAGEOUT happening. From what > you've said earlier (how effectively policy works) I have understood you > want to find out how a specific MADV_PAGEOUT effective is. But there No, it 's not a specific MADV_PAGEOUT but system global policy. Android has used the ActivityManagerService to control proactive memory compaction from apps since it could control life of apps. You can think it as userspace kswapd. > maybe different callers of this applied to all sorts of different memory > mappings and therefore the efficiency might be really different. As > there is no clear way to tell one from the other I am really questioning > whether this global stat is actually useful. The purpose is global stat.