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 1F185C48BF6 for ; Sat, 24 Feb 2024 19:03:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32A656B00AF; Sat, 24 Feb 2024 14:03:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DA486B00B0; Sat, 24 Feb 2024 14:03:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C9AA6B00B1; Sat, 24 Feb 2024 14:03:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F3A516B00AF for ; Sat, 24 Feb 2024 14:03:03 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B531680397 for ; Sat, 24 Feb 2024 19:03:03 +0000 (UTC) X-FDA: 81827619846.28.399647E Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf21.hostedemail.com (Postfix) with ESMTP id BBFBE1C0008 for ; Sat, 24 Feb 2024 19:03:01 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="kp5EO/Km"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 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=1708801382; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UhcSscs85wNXxHEhMwj3NRfrA4RkqpWaACG5xAwZhsw=; b=l7KAKhcYZoA7uXzD7LJTjA95yIXpiADzoZmMZEwLasJRuMGBWfjG/5kOaFtEimuYVTARH0 2o//KIpZCLy7LjsegOWdNrN2Ag3Aa6Ni6FkkRtUiZfd1G6/aHeBux0I5u+zk5RhLPdZ9Lt +9x0vnN9jojhMOJ2sMD5cTCAVQ0DgGU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="kp5EO/Km"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708801382; a=rsa-sha256; cv=none; b=1xcV0/ZyCnoXzgmo5vfIIWx/OHMpi14pgoHW3m1sUljYYaZ7lhOzIl4To5nZnJyFTuqW2s 5G9jP61Zgy8N3VPZTrdV506Hw6loYucR0TI4U90mAbMcT22x0B4KFTEMORhmrz9pT966iT ZjF4hLtAAKzexk5UZT+MKHc2+fklemM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 4D47CCE03F2; Sat, 24 Feb 2024 19:02:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C59EFC433C7; Sat, 24 Feb 2024 19:02:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708801377; bh=CPTtSiUAW9ek5cTfmW4yjbTl4pvfe0S34pxaaji0qt0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kp5EO/KmpcW8kIT8p9pkV+DJRwCxsTo5qK9ZNPbp7EuyISsRR7rSfdBwyX5B0R+gf /1paXPhJrqr8VrlW0UqFrFL4Ys8CarZxhYj5DiTp2IB9CGXBfZtNwHuK+SerzPq14K aEI+wP7dxdUt3wvL7cbLHDbZicbyWxaKg6PTYZy/xDLrKArwTUDnTcq0RGLMbnIPcN TcAIA4pr5hJEapNY9OmkJLNZsp2R7WFCQtFX131y47g/HwJVP1VPnpZYp8MyflBRWj F6VtiIWneS27exo6lV/3tj/wS/UCJ7+utbaN1sgJaa8gWg10GaEzoaUmMYCz9qmXj2 QRcXF/Eph1ZDw== From: SeongJae Park To: Barry Song <21cnbao@gmail.com> Cc: sj@kernel.org, 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 11:02:55 -0800 Message-Id: <20240224190255.45616-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240223041550.77157-1-21cnbao@gmail.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: zx8hez3byf8aq8cm7bhbfi95588hyzgc X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BBFBE1C0008 X-HE-Tag: 1708801381-729742 X-HE-Meta: U2FsdGVkX195ZNIe9f1glMF2a8bJ7SNpRslc3dtWdr/rN14tfsL4iSy/OFcnR9nGRafs58Bfh83YmyHPZ1bVKfzHJOBEh0NK/VPX3Ct0fMls9ZV6wA6MFmGhvhcaXeuzE8HU0cbbdMaKRHbqG+41SZbd26nKCvml1Jdv9v/NQUMGiSIBoRvlcCcKA31tMfe9uT8/jc3K+NanD35tyyGml16AxvWXIVxuUPST1QxcSCTEDB9E3ar48A49BE5Ru9qv7HnMH/oHF0C6miboiHbHWKIsWVPRY+6+LtsNdR83smXITbwNamQALeal0/M63TjLVq1S4xIG+N4YDItJOLPh2TMF0+B9KDHOijutjLvYaDl5C7xdkqkXIYZCoK5BsoOi/yOudMRew0WV94wmyTu4wjeCx2hnnZcFn7bCCwOLZrGA29G3LPXV2d6gyKSjsmAX/wgRq1EpFoQF0dbe9d+tE9hamoZHni2SGjCJo4GTcg+QXHKMK8e1zS3JZzBCcKDx6rEImttbj7TToX2SyL7FtdPcfFGLnoqdnmBl7F45Ii5Xf7EAsUc/VClZQpd2IN/quD83sXk/PJ7WQRoPvhpCm61W089Cf/cZ6d1pGfJDAn6n5oGV7UC9EgqJ6O5RrNhq3Y7tDcCidQLiuIGRlpUqp5r/cOqRJrHl4zIvoV+JMURVLvQ7ZgVOQGEZcr8iZEd/Z5jkqmsoDbNyI9F8VwBKHQgaA2X5zieF85I8y7tcWh5LvcLs10NL6/DMjSl0a/HqQYXdn1x0/iFSDAucbtyLEgT4MFawVAOJmN/O+zIPkdz+ctaDC84TqbK6wUiGfh6zx68LesxmRkIBUgPSghkcaMW1BHouhbW99OLCE+nnWryDxEwou01MzIY49wWHrGlgHfHPsj6/hwikmWm/s781gyt92YToMR7E2vqWHxXd8x0= 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 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. > > 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. > > #define PGSIZE 4096 > main() > { > int i; > #define SIZE 512*1024*1024 > volatile long *p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > > for (i = 0; i < SIZE/sizeof(long); i += PGSIZE / sizeof(long)) > p[i] = 0x11; > > madvise(p, SIZE, MADV_PAGEOUT); > } > > w/o patch w/ patch > root@10:~# time ./a.out root@10:~# time ./a.out > real 0m49.634s real 0m46.334s > user 0m0.637s user 0m0.648s > sys 0m47.434s sys 0m44.265s > > Signed-off-by: Barry Song Thanks, SJ [...]