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 94DD2C54E41 for ; Sat, 24 Feb 2024 20:02:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB19B6B00BC; Sat, 24 Feb 2024 15:02:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D611A6B00BE; Sat, 24 Feb 2024 15:02:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C512C6B00BF; Sat, 24 Feb 2024 15:02:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B6B366B00BC for ; Sat, 24 Feb 2024 15:02:58 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 883D0A0FF9 for ; Sat, 24 Feb 2024 20:02:58 +0000 (UTC) X-FDA: 81827770836.07.3367F28 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id F113240018 for ; Sat, 24 Feb 2024 20:02:56 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GO3LnLyC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708804977; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pF1RRlDdTuTLF6oO5UHvSyhdrX1IQT2ZnC5uSsF4cwk=; b=uUl7zHs82A5O0/PbVu5ibNynLT82QAFsjgEK/oCMjRWB16Ve1a2kk/x/Ec/9M4BBHRo+i9 RTYJzbTdqGsZwDzW1kNFXFuN6SZPe4x7WPjauHh7qk1AtPztVVhrS/171WoS13PDZ23MWP Nv/I1JzbJUoSf87I/EM8n99+DJxyC4E= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GO3LnLyC; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708804977; a=rsa-sha256; cv=none; b=46in/P2nf73+MZY+dJFd8hY18ExFFZ2LuyhPC8+rh4AORhenDOOGYs6dshnKLSBSztmuvr /xB1D7512jFtiDW22qNv8EQE7QPgaNon8slVHjCxSIdpuCEEmIl+pU9cO0Uz8Q88LxIlFE kyBy5b9WTpZdlKQ1PK7xZ6fDfcYln3I= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C5E1F60BA4; Sat, 24 Feb 2024 20:02:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7D66C433F1; Sat, 24 Feb 2024 20:02:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708804975; bh=Lyx+jlo3VcjazLK7FnQNRJu5zo/lPcZOySRjMGj+3Zo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GO3LnLyCVMf46dnvqDxxfaXQJmLSC/y21eTEmcUy97WIlimYqNFHYqkAFAz41gW3a Rk4Q4KzKxa8IdiptKMEaObfYFnu84PMWHvJTtjt+au5ZLOVsqJFju9d+8+3yCXhZsd TJ0W7QMWcR9eCEbXO54SmRRW6A468yVm1GSZTcn7qv8WxPn7/X7sdmghe7ivAFxQvQ V3phuCbt2eBOELhQIrrhfRHhoPvsSqvneebbBmG2G8n/SDJTVF3I4U6h9ixZjFP48y ARZ2U7zsjiI52R2+O7KwO3wbbYrGXUb8fElgV/THkK5lnu4iL1xcxW3FcVF3gi+TlG bTZ3PfSil9ddw== From: SeongJae Park To: Barry Song <21cnbao@gmail.com> Cc: SeongJae Park , akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, minchan@kernel.org, mhocko@suse.com, hannes@cmpxchg.org, Barry Song Subject: Re: [PATCH RFC] mm: madvise: pageout: ignore references rather than clearing young Date: Sat, 24 Feb 2024 12:02:52 -0800 Message-Id: <20240224200252.46329-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: F113240018 X-Stat-Signature: ee6eewp7rmm6o938661re95opf753bi9 X-Rspam-User: X-HE-Tag: 1708804976-975375 X-HE-Meta: U2FsdGVkX181oSjNCuok8ROsw67UQdTk2zbHrlxOUL5RXKQzt+PgBDhzlTQw1VRPnIAwukdPyF3OxRwbGCib0v1N1BWsX5m8xmttX6a2JVLRO0q7wf+RDGjt/WK61U1wlqR4PvB2uVqdLjmwstymtvx8G0yw4j8SBs5K2UNiWDZtTeYZxbWWTmnNmE+28mwiZ6pYdB4jawxq3FN0BiWspwAr+/P6sBlJRZcUEn+lzT3/IM7zZVqRwkEVMpOz50b4lt02WZMas9dgHNDmSJMpyXSfTYaji9EMI7hdWuJScFYRxs+o9BS/Ee5wyXtIXmteU71VE3eA2Wxh4upnN3WteNeKFdY1DZeiZE+W0NLC2R54k/6OTWYSbW/dnhQDSMaDBK+ZmEijh2jSL0garL/9NneQIGhyw900p5V4uWaGhvHrV+cHqJCnYDqcTjeQyygIJhX7Ob7yTwLfRssj5eDsGPNaMemdhi1ykbRDorM4jN5iweE6BrzvgiPK1ZXL7BQsfghHsCRm65SJoREVao8xY9w7QygJF61MUM9ETzB+Iet0d9ajyN7tr1fZMIugwt3TBJA9QpX+2y4yqZD4nfDSeRiCvsRHqKXz0Tc3XaveCJKYxRu/7PSm7KRlRnH8D3gXLZpE7O5rgch1PHQfgj9p8AJfDXxTiWIqUm5KleVErDD/0kC6IXCg3KMIIapcMz1DKsgdGhxe/isYuPxIK36qn+jONTF3AWl5xvxcrRN1NHq3su00xRZGtiiV7mFrzufgLJkWxIS3ntUXstjAO3cW1ZO7JmNfM8QBjCSsTeqq1drlQdmHhlm1jua4kFmDugojn6PQ+stQsburyS6aaoWK4GOWXHCCQXXmjhJtQnzrxUjzPvBYBraHQ92L1IBRUgjy/LQB4VP6gwE= 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: List-Subscribe: List-Unsubscribe: On Sun, 25 Feb 2024 03:50:48 +0800 Barry Song <21cnbao@gmail.com> wrote: > On Sun, Feb 25, 2024 at 3:02 AM SeongJae Park wrote: > > > > On Fri, 23 Feb 2024 17:15:50 +1300 Barry Song <21cnbao@gmail.com> wrote: > > > > > From: Barry Song > > > > > > While doing MADV_PAGEOUT, the current code will clear PTE young > > > so that vmscan won't read young flags to allow the reclamation > > > of madvised folios to go ahead. > > > It seems we can do it by directly ignoring references, thus we > > > can remove tlb flush in madvise and rmap overhead in vmscan. > > > > > > Regarding the side effect, in the original code, if a parallel > > > thread runs side by side to access the madvised memory with the > > > thread doing madvise, folios will get a chance to be re-activated > > > by vmscan. But with the patch, they will still be reclaimed. But > > > this behaviour doing PAGEOUT and doing access at the same time is > > > quite silly like DoS. So probably, we don't need to care. > > > > I think we might need to take care of the case, since users may use just a > > best-effort estimation like DAMON for the target pages. In such cases, the > > page granularity re-check of the access could be helpful. So I concern if this > > could be a visible behavioral change for some valid use cases. > > Hi SeongJae, > > If you read the code of MADV_PAGEOUT, you will find it is not the best-effort. I'm not saying about MADV_PAGEOUT, but the logic of ther user of MADV_PAGEOUT, which being used for finding the pages to reclaim. > It does clearing pte young and immediately after the ptes are cleared, it reads > pte and checks if the ptes are young. If not, reclaim it. So the > purpose of clearing > PTE young is helping the check of young in folio_references to return false. > The gap between clearing ptes and re-checking ptes is quite small at > microseconds > level. > > > > > > > > > A microbench as below has shown 6% decrement on the latency of > > > MADV_PAGEOUT, > > > > I assume some of the users may use MADV_PAGEOUT for proactive reclamation of > > the memory. In the use case, I think latency of MADV_PAGEOUT might be not that > > important. > > > > Hence I think the cons of the behavioral change might outweigh the pros of the > > latench improvement, for such best-effort proactive reclamation use case. Hope > > to hear and learn from others' opinions. > > I don't see the behavioral change for MADV_PAGEOUT as just the ping-pong > is removed. The only chance is in that very small time gap, somebody accesses > the cleared ptes and makes it young again, considering this time gap > is so small, > i don't think it is worth caring. thus, i don't see pros for MADV_PAGEOUT > case, but we improve the efficiency of MADV_PAGEOUT and save the power of > Android phones. Ok, I agree the time gap is small enough and the benefit could be significant on such use case. Thank you for enlightening me with the nice examples and the numbers :) Thanks, SJ [...]