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 AC67BC52D11 for ; Thu, 26 Jan 2023 17:10:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C7546B0072; Thu, 26 Jan 2023 12:10:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 277E58E0002; Thu, 26 Jan 2023 12:10:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 118DD8E0001; Thu, 26 Jan 2023 12:10:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id F256E6B0072 for ; Thu, 26 Jan 2023 12:10:52 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A9219A0E08 for ; Thu, 26 Jan 2023 17:10:52 +0000 (UTC) X-FDA: 80397589944.29.3C974F1 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf18.hostedemail.com (Postfix) with ESMTP id 9C92F1C0026 for ; Thu, 26 Jan 2023 17:10:50 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fU4OqxdO; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf18.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=1674753050; 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=bHSxHTN/xxsSqL1X6+bbClQ0gPOZ5UgPl/bWkZa4aoI=; b=odkpTr8vaqLLG4ylWfiVxY6T4xOmE//kzADVjzTV+U98B1zwq6q3GagfR8xzz8LbMb+6pg VqMHPIAjl6N0uE3g6Ig8wnJRpGtNZCJvwnr7tTDTXcbttaZ9HEV5g7bQ0NoTQvbo4AMEKR 3xOkgtkpDzzUw2R4cnYeWLEc5vishsQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fU4OqxdO; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf18.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=1674753050; a=rsa-sha256; cv=none; b=NlOiCX0VKgIDWhKID+e3r5uxnA8UE5WsAx2I1LNPMNFxPSJ/lojVWtG+DWcTLLjZyNtQhc KwFP722aTrAYcfMjw4l7Ej1+Gq4V/WULuCduQ6quauGahUpI6Vy5STDu0kBEm+F6Z93zvL lwcYWAAxTZNMC4D5B4Jvs8VaFwY6Ojc= Received: by mail-pj1-f46.google.com with SMTP id x2-20020a17090a46c200b002295ca9855aso5911100pjg.2 for ; Thu, 26 Jan 2023 09:10:50 -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=bHSxHTN/xxsSqL1X6+bbClQ0gPOZ5UgPl/bWkZa4aoI=; b=fU4OqxdOfzhOFI2T9roAZ/91c5Mds5p9COSMAU5dKwBdUdNzl8gPvVSXMFfG9Q1+fE eKUs8QFwj/haRH4w1c12B1xpXSKEsRDdQhcfP4QD+2hfYhTA6HKaVv5tDRVIPulPdfZf xyaT378l85JJBbfG+hauZm4oKu1XfYR2v1os5c+DEYF5xmvLVqbC33thFAKd1Iy0WKIY GiAALlfVMxA33XMc3DhKKfXIVYTEmBso+cXCNMWA5eHbIPk0XrUUS8P89/G12P745nn1 AAUxXCcyebKwSPWheeKZLnZitpdUfTaaY4Maog98lKEJ0SlUNEfqjGCIe+drYVFf7wun 4Neg== 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=bHSxHTN/xxsSqL1X6+bbClQ0gPOZ5UgPl/bWkZa4aoI=; b=UTFU0Wwvf8lNB6a8/D3VrHrQb/ciGZEAyBFflQGeapXh6REgKdp5QbRXjWUMYpItlu 6m32STEPWfGFr6qPjnL+QMVsuTz+yevC2QcvU8K/DHzEp19e3HlrN/2TAvQOCc2+1Qfv ot8EooA+Ws6cglM70l9vgJC+SM8vD7YEzWLUFzlEp+I9cwB2oUT4qWmqz66cIlEF5E3e mQmrDMShATX4H/8Le75kda+XoPcxwxyjxSJyMoMWt1pRaZfoMcXWdZN5jkR9PCR2afdL v9K5Y66LL35yyItnSnJ4Rxky01wtL19bOUCDt0ZY+dagy52/pq3zgIWIWzFg6zHGIXFk 11GQ== X-Gm-Message-State: AFqh2krreELG8ZekNzpBiwMy0338zm8H4zDxpAv9dHKWoSRPIeutAFjC XcRGr8DRIINSVpYhtEu9vdk= X-Google-Smtp-Source: AMrXdXtNg42Md2CR5I1OgvQN07SpRon515/tJPdMycmoCckatTyTyjuhc1j0ySgxbSFt5zJte1R51g== X-Received: by 2002:a17:903:2306:b0:194:7b59:bfe4 with SMTP id d6-20020a170903230600b001947b59bfe4mr54751382plh.54.1674753049158; Thu, 26 Jan 2023 09:10:49 -0800 (PST) Received: from google.com ([2620:15c:211:201:9ca6:45a6:69fe:a468]) by smtp.gmail.com with ESMTPSA id c5-20020a170902d48500b00190c6518e30sm1201667plg.243.2023.01.26.09.10.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Jan 2023 09:10:48 -0800 (PST) Date: Thu, 26 Jan 2023 09:10:46 -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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9C92F1C0026 X-Stat-Signature: ghyooiaou17tiszcuuwcnfeyyjgnhaeo X-HE-Tag: 1674753050-343359 X-HE-Meta: U2FsdGVkX19wUUicsUWaIGaHbdmpFrhLNGOvO769UbqOdwqVIolUzN5jZYLmCsuCs725t+bURN7aeETkMS11cQL7m8anquRjeqkQKGG1xmJ6JfglZi2H19LyFJUzqX1D0t58Eum39kH3qXfDFF0TYEDQOp4b1Bd+Ey8WkoNED7NCVHCd6KFC2p/gtZYx1deQZc8rYD0NzABbYVBzcO/QtwtHPQroGXsD7TYoxjqR/45S1wDx6V7ZeZrBUKo+SNVcv4MMWSF/XCSP83totMvMQfcQy7SpXShmMqf/rZJakZIXJeTbKjkLjeKYAaEBehtLut6eWE+7RucOmwUenwbedD3N+j60sWDhOd4Yx+g/eQdZNS8OxU4jgEMfJ+NRiokFILU6YC9BvPDPBAywsgT/L7fEzwGFdVR/bx7mWKvXUjsl60CrUllfiK2jzb6wlwLEYTG8i1/kR/DuPxDxaK0UjtG/E1vL8xAiyJ5X10ReuX5xoKeMViRYrJGl7e5eBv6/a1SMe/5teKrS7RlqMFuZaYYrAxYxwtD9J7rdqozKCvITg6IbntImwLCDMR0d9muwKlEb7zVFOBPtRti32U890QbeT3LhJDHlhYs6Xq6j96mB1/vhx2a8wwwQ/fLBzR32xkkg5nsLZsoCQWzZnXFaymB+ziNa2XlPZZPfahMqzIXpGo3Dgg8DGJs9exSlSeBHkgk0TwDlxiTlAznZsEVK9H5ioBdMmigeuU4t+1/8GyEziMnjS/pvcomNgx4U9ZEP0dSQAZ17VgobPNIxajdk5qy0QHoyuEZCabXn2b499SNYNVzwyzJqt7GRK4+KfyWfujJBIder5lW8rrtvuXPM9s/Kj0DKKl0LqZJcn+d0q0Iq9Y6USvGPTb6o3VZGfhCYVyoR5jXr2aJ9hTzYHOZyOpvDIGGwPXU49wiWWshCfEnNqCSWLVAwXxjabuXItXPbNMIbOuCCnf9KkzgqmXA PrZJ1sjs slyCpcJYYVCvXpBswU2dhb9Yf1AGKbJ6kKSsh8mlnosFU+t2uZ6xwt9OWsjATfpYyaWHEHtc2aWPn4jiJeYIUfVw28mxAhHnSQUm/k3mC3wNfQ9bicsw+e3AX0qW7QUdGemZYvmYCrUxSMPUocfxFs2Q65EhTsD2ieC29Zo9nq73pEGopFW8fegi+TbCqLUXqc7HoqNbfIdVaqQ6nid/3znvkWGTR2g6bE7B0fHzIqkHR6N3sMTek3GpEBLhOqWxHx9IljHllvGNeUzkO7oR/pJHad9M+D7ww8gXdojFIfwRkXQheK8qmjbsssUf0Jz5++7c0APQcvnKxDLJvF1qH5IdeaewFIioi6Nof6RwtNQWB2VsIxuNWJeSZtGgM1T0THi8X3/McW4SgI7Vswkk2tObumAQYkifIxliSdZSJMQxQErHZy4xRc5B+BqjugsESL3EomPcqW0pU9Vr6VD4aAdSIa1J1dL8u2AU1UaHiM/Xqa5hx2XfOibczNgQkcyH4RKtX03OmgJ7b4tcuhnAerS9bltou+ThcTe85UnG8/rYrLtn6z0Ojfd/L/fVnJB7PiRCuHboWlDxLVtvDeri3JrRvorsIx8/B9Clo 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 Thu, Jan 26, 2023 at 09:50:37AM +0100, Michal Hocko wrote: > On Wed 25-01-23 14:21:35, Minchan Kim wrote: > > On Wed, Jan 25, 2023 at 10:37:59PM +0100, Michal Hocko wrote: > > > On Wed 25-01-23 10:07:49, Minchan Kim wrote: > > > > On Wed, Jan 25, 2023 at 06:07:00PM +0100, Michal Hocko wrote: > > > > > On Wed 25-01-23 08:36:02, Minchan Kim wrote: > > > > > > 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 is just too vague for me to imagine anything more specific then, we > > > > > have numbers and we can show them in a report. What does it actually > > > > > mean that madvise_pgscanned is high. Or that pghinted / pgscanned is > > > > > low (that you tend to manually reclaim sparse mappings)? > > > > > > > > If that's low, it means the userspace daemon's current tune/policy are > > > > inefficient or too aggressive since it is working on address spacess > > > > of processes which don't have enough memory the hint can work(e.g., > > > > shared addresses, cold address ranges or some special address ranges like > > > > VM_PFNMAP) so sometime, we can detect regression to find culprit or > > > > have a chance to look into better ideas to improve. > > > > > > Are you sure this is really meaningful metric? Just consider a large and > > > sparsely populated mapping. This can be a perfect candidate for user > > > space reclaim target (e.g. consider a mapping covering a large matrix > > > or other similar data structure). pghinted/pgscanned would be really > > > small while the reclaim efficiency could be quite high in that case, > > > wouldn't it? > > > > Why do you think it's efficient? It need to spend quite CPU cycle to > > scan a few of pages to evict. I don't see it's efficient if it happens > > quite a lot. > > Because it doesn't really matter how many page tables you have to scan > but how easily you can reclaim the memory behind that. Because it is the I really don't follow your claim here. Efficiency is input vs output. For the those advices, input is number of scanned ptes vs. number of hinted pages. If you keep need to scan the sparsed huge address range to reclaim just a few of pages, that's really inefficient. If you keep hinting to the non-populated-page, already swapped-out and hint-cannot-work address ranges, that's really inefficient. What do you see the problem here? What exactly do you mean "how easily" from your context? > memory that matters. Just consider THP vs. 4k backed address ranges. You > are going to scan much more for latter by design. That doesn't really > mean that this is a worse candidate for reclaim and you should be only > focusing on THP backed mappings. See? I don't understand your point here. The stat doesn't aim to make such decision. If THP page shows the good yield from the efficienty above, that's good. If 4K page shows the bad yield, should we focus on THP pages? How could you conclude such decision from the stat? The stat just sees the current health of the system and find something regressed/improved compared to old to intitiate further investigation. > > I suspect you try to mimic pgscan/pgsteal effectivness metric on the > address space but that is a fundamentally different thing. I don't see anything different, fundamentally.