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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A78FC27C76 for ; Wed, 25 Jan 2023 16:36:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 829C26B0071; Wed, 25 Jan 2023 11:36:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D9A86B0072; Wed, 25 Jan 2023 11:36:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67BB46B0073; Wed, 25 Jan 2023 11:36:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5464F6B0071 for ; Wed, 25 Jan 2023 11:36:08 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1E94D14082A for ; Wed, 25 Jan 2023 16:36:08 +0000 (UTC) X-FDA: 80393873616.30.2688218 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf27.hostedemail.com (Postfix) with ESMTP id 2B01740019 for ; Wed, 25 Jan 2023 16:36:05 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VXfFN2sK; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf27.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674664566; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7gjeuMBJi0E7usVDBoVD4pYljRyA65e2p6zLRcXsT+M=; b=sZg/u3BkgCQoVSBS7ndjvunFX93cfg4Bv//dGAcJxD4vpropsviOhcG0GTAA9NML76gfEZ O3qT1tf1fKxpV+AXLTzRv3vPpiJ0wjUy5GmAtmFMIEb3oSa38B7HujwZ+aDTLySLBsx+Ut CKCJdyzTlR80rCseVnbBGo2AG/b/qqM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VXfFN2sK; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf27.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674664566; a=rsa-sha256; cv=none; b=l/Pszv22vQnEUzItPM3F57vIfQ4wyGNYf5CDrmyjV4lwiUPFKgeqGd3SzM37chtBR5BEpb P76ujlq6y4pC1vDOOTM+Jh2mqRdfixfX4V1hB5oAIubTY/wt3/0hlDfkPAbLLaLKh56nvT T9jeXn2pjqE0LLM4n8lpPFB6Q5INtu8= Received: by mail-pj1-f46.google.com with SMTP id z1-20020a17090a66c100b00226f05b9595so2612826pjl.0 for ; Wed, 25 Jan 2023 08:36:05 -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=7gjeuMBJi0E7usVDBoVD4pYljRyA65e2p6zLRcXsT+M=; b=VXfFN2sKcuFtMkOJIK8FnEGx1n1jbrqkbh8aiLnDr08t3pVR2Keo1+ky3+1H/44+b2 eRQWoH3l8g+sCNxO1r9nyIQRntey7cVzUGkrWAkaLOOnS3v6iFiLwyXaQhvjwYvNdZdG Wt+vTb0tP8Loz9+o+otoPbL5JEk2/TzH3omkxZ1Ubc3BqOWQK2rSfos5PIrtxmTxfInx x3xdcvxy9EUSgMCN6cvrL0IEVvRTEVQdtP8Q0scW/C7FomOwfJrLsZvdnoRQw6QSl/HS 1qliWz0eL4QenyVdz/GnuP6mNdcxuFQx280g0JM0VqiS98AB/AQTasu/oKuNUvsUHDE/ C0jw== 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=7gjeuMBJi0E7usVDBoVD4pYljRyA65e2p6zLRcXsT+M=; b=sDYBkJoyxrjKejpgIT5FNRGoELg985Jc8ov/I+pXLRf2lo6FEih1ugaZU9kyHXlLES kr8lNkiYCf9sSwXSbC+Rhy94EW84T+vZTUnwBAva7vJFVs2cuxBEjHT5iuA4Tl84j6tx q2Xp9stZUqjgGqQCB6qUlkOhmPemyyt7tmb6hd1nZgUMWo2PNLwbbIA+IRzhnlEmizaX 4Nivd+FANNo2MoBQMLnRs4tOLghvxpjOJnEYRzxTfEmsWvRebQyv6VAaxv1D9MK5nPKM lzSBvqQmdqXabRpAYLZ6IYOq9oSb3RMjGJzfEGcBhOunp4K+DPTm4wO2qFuSIl5TvGV+ cVKg== X-Gm-Message-State: AO0yUKW8FWq1ARjlw+rnCs72I/XsPP68fUku2yi8UAPBhSfhV5OTAhLE o4eRx9E0gizax95OrN3rkiI= X-Google-Smtp-Source: AK7set/i3ZvdzEaAJdLRUPlgempqiPaRSIpBTyT+N/jDTUIKj0/ls1/6tauzQhTnyOnat1LPlgKejQ== X-Received: by 2002:a17:902:e848:b0:196:32fa:6993 with SMTP id t8-20020a170902e84800b0019632fa6993mr1749025plg.66.1674664564769; Wed, 25 Jan 2023 08:36:04 -0800 (PST) Received: from google.com ([2620:15c:211:201:4ff6:fb01:3677:2696]) by smtp.gmail.com with ESMTPSA id p18-20020a63b812000000b004cf643a425asm3385177pge.61.2023.01.25.08.36.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Jan 2023 08:36:04 -0800 (PST) Date: Wed, 25 Jan 2023 08:36:02 -0800 From: Minchan Kim To: Michal Hocko Cc: Andrew Morton , Suren Baghdasaryan , Matthew Wilcox , linux-mm , LKML Subject: Re: [PATCH v2] mm/madvise: add vmstat statistics for madvise_[cold|pageout] Message-ID: References: <20230125005457.4139289-1-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2B01740019 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: cpyqnqqcxne65ocdd5ore3scx33q8pyh X-HE-Tag: 1674664565-348955 X-HE-Meta: U2FsdGVkX1+bbmJ/GUDDs1MWuLWjUPFymNOaBpClZ8QHAst8lc2Xqghm4kmp0rkOfNMZtEH2if1i2CvInrkLRuw1AdiSRlUl+XRdvTlBrpF3NjdHp2cl9dBY2szCmmYXy5etEa4zW+t/FtsJw2zGoH8tvNVMcXViKPlAGM6MOZHokrdMzsrPnuPBkn2dXrUBTba+PUvJdO1C4wnGKV1fOEN5l7NOqQrFfk2odoMDOJ2YYsaSvQsBY30WaoCdhqZuGXK9PWu5pzyLZnoRl3LDw20KwdXV++awhPjuuNsK+0uZY/b4wTNCchEbuqEFFmkBmFrMN/Bl4CeKJF8L5r7jlgLc/9Suw/4GXzkNX9tlgG0FSk9hiek5ordUCU9DMfZhsfYjxAQE9pR9JCWFzM7uVj90sKfYNkOtA6j/aPH1JioSqM6qwPW+Qb7kvVqPyNLwSuVwmPzcghq83VE9rxG2G8BahtxkBpx43DBa4/acjs3WDzLe3MXtjyvaoCOFof5UxuPgksJdP0/MeDXQuSAN6c6mVfPyXL9nJV9xLIBRw41LvFu5wR1hy7PYwLPf2MjXxpbhd1Djf1ivcWPOu6n5uGUb2yQLlYnhtO8LkWAD32Z0PO33G1zXv55H7M9iDAEyDiLuKfHGMgC4g3xQzhvRXhQxkzp8o+w4SznSyck4gfmhVGFxozsKUBUxwQez/hTuzWkT21GeBveviX2L3nT8TzXR+mL/9d3OOBOXtjkNsz62jTZjZZY2ligZdAGU2xWn4uTLzowL7wr4YfmSgrS9ffXvfG2E9i90iIRbzPSG9u8RBkBV5wU9+wL3HRJ0D2YWBO3NVlek0dNB3aXQ+QzVXIVJEmwMgiJAaTIyVtXZbuH2KdyXMC0blG0wDZ79eULzSOjqRfT2vurO9BaOl7wRVEPrsZ8fIMTOlI1HKqNPG/btJ5UFXEeRu+Tih9qhYM6CWqenZM46Z3ZoXTYBTrh 1QE3y235 7QLbxD8VxXysun5yxp/Pja4LkLF5jSqEl7AJP38jczHTRLmZpv5mvePTfYxOsnB/QZf9+T6QbT27VR0JPOKOzH6HNPbuYtkERMuqqhnd3Hu4vY6rEQ8Lf4ud2HZYh9YO1CNfmDQxodxhc3JMdy/k8HWoSFIc+2Vm1IU6xEeFBLyUi3VZrQKggHDChhDJlzxbz/ylP/gf0nIVkWhw6XNq4sdd6v5qI9KufnzUfHH6sVjbiLK5lSGTgdvRGDBIAD9iOIGIgcj3o8iSJ0rw4iYjJDSz0H/tBzWdt+sT/1geu3bqFwyaEooxzXW8Jf+3TA+UzMpQwE6iZlVWF4BRzdMx+IXLa/l+f60XXRCO9JSWPKuFtt5DW+HsgQuUBlA5C89N0nRMG5HV4wHgnxL3W9oyR7HfirU9Nf3XB3f9o3OxlRB6jXy2OWQjvPGqHe+aOOyp5aOHNfCUfiXIv3XbG2Zu31mQLcIWYZ9K7g8gvuyEH6rY0O2QlxJFHwrvBsXTq8Ok3XjDD9FJ6tDo1gFj4N+CTs9g3x55Gq59PMypT1E60swwBy2pPi0wx+BWex4lSpYZDyIflrIc+YkFaty36QpfoP20eeg== 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 Wed, Jan 25, 2023 at 09:04:16AM +0100, Michal Hocko wrote: > On Tue 24-01-23 16:54:57, 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 adds those > > two statistics in vmstat. > > > > madvise_pgscanned, madvise_pghinted > > > > Since proactive reclaim using process_madvise(2) as userland > > memory policy is popular(e.g,. Android ActivityManagerService), > > those stats are helpful to know how efficiently the policy works > > well. > > The usecase description is still too vague. What are those values useful > for? Is there anything actionable based on those numbers? How do you > deal with multiple parties using madvise resp. process_madvise so that > their stats are combined? The metric helps monitoing system MM health under fleet and experimental tuning with diffrent policies from the centralized userland memory daemon. That's really good fit under vmstat along with other MM metrics. > > In the previous version I have also pointed out that this might be > easily achieved by tracepoints. Your counterargument was a convenience > in a large scale monitoring without going much into details. Presumably > this is because your fleet based monitoring already collects > /proc/vmstat while tracepoints based monitoring would require additional > changes. This alone is rather weak argument to be honest because > deploying tracepoints monitoring is quite trivial and can be done > outside of the said memory reclaim agent. The convenience matters but that's not my argument. Ithink using tracepoint for system metric makes no sense even though the tracepoint could be extended by using bpf or histogram trigger to get the accumulated counters for system metric. The tracepoint is the next step if we want to know further breakdown once something strange happens. That's why we have separate level metric system to narrow problem down rather than implementing all the metric with tracepoint. Please, look at vmstat fields. Almost every fields would have same question you asked "how do you break down if multiple processes were invovled to contribute the metric?" I am fine if you suggest adding tracepoint as well as the vmstat fields for further breakdown but only relying on tracepoint and frineds for system global metric doesn't make sense.