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 A3D9DC48BF6 for ; Sat, 24 Feb 2024 19:51:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C94F06B00B9; Sat, 24 Feb 2024 14:51:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C1DE86B00BA; Sat, 24 Feb 2024 14:51:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABEC36B00BB; Sat, 24 Feb 2024 14:51:02 -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 973C26B00B9 for ; Sat, 24 Feb 2024 14:51:02 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5023114024F for ; Sat, 24 Feb 2024 19:51:02 +0000 (UTC) X-FDA: 81827740764.07.2DAB7F7 Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) by imf26.hostedemail.com (Postfix) with ESMTP id 86D57140007 for ; Sat, 24 Feb 2024 19:51:00 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SXmzHAR2; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708804260; 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=OFYaLycgFe8j4foajRXoyAWo+795ANMIvzzRfRsQJF0=; b=e4yWJdx3ZYuht5CXfo5/VfCzkgAz1tdXEqQvRWCADjUyjU4L+YAYJ0V6Z9z25F380X8s3V wKfV4zlJ7YXeK9gjMjUZpSw2ntGpEA9WcllWiTmt+WWmn2leHpOB2ssN98PjF4+OPYsWFd +2yu7DVpEcz63aW5oWBkW2QocXHiacI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708804260; a=rsa-sha256; cv=none; b=8aLih9J0rcQ7IvktAmke2+TOfCSxoVHKxnwhcuQH47ET78/we+ReWssAg+Vyd0YUSD4Srp AUQ8Kts06jAh25COeDGWFAnxuferxKVK+g/Vr1M+K1EF68f7BQmta7dDrJGGGGFvqWQDuF qruKaONfUf+ZyjXKYq/HNKZk2/IBo1o= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SXmzHAR2; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f52.google.com with SMTP id a1e0cc1a2514c-7ce55932330so983609241.0 for ; Sat, 24 Feb 2024 11:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708804259; x=1709409059; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OFYaLycgFe8j4foajRXoyAWo+795ANMIvzzRfRsQJF0=; b=SXmzHAR24mJHzBoWX9+qNl5LFvEBRjGSIB2amNQ9aalnfMD7Flrz4WdbRwElJEJ+mM koLpApex0NyxNb9XrsnjquO8trzEquVz3cMGlBBX8MFkp67iafAR2ePkZLGPAPrt1Itr XISK9wY6yjUxpv6A3ZHER/TfU0aeLKUXzZGQK3G0PLk8tadojzff0c2KFjp8R4hUrRqd LlqZ5UNkO+AorsSe+w3/lMHmwsv7SWe+FW3dX9ZHc3QkGosyQSWnFxBQZCiyssBfntAq 1xPqozGcCtFSclK9u1XEmdutyfAp81CWEsdij4AWW2OXjy7hhVMBxqviuJwNxGnj3O8q R3XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708804259; x=1709409059; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OFYaLycgFe8j4foajRXoyAWo+795ANMIvzzRfRsQJF0=; b=XkGIUDlzt7KDi1VvBQdy3dN08ancaesKLG66GsDjpgNwGPxA93i1h6PneX+75faHOV Ay4fGmdvB0k4xZZaNs+esbj8QPAiukWmAFvvv7yLFFV0Nhhb+J6qoA73FkORw8R5Phhx FuwdlODTxkuZ/iGrtJNWTjj+tOSZ2S5W6kZyUL98/3lMDwunKfhE2Qoy32yP/A1OsO4Z QMIkY0k6zbUt97snveDEvob6pqqKy9gWX31Sc848/TihGlz59r+cRhnYgEzjDVp9fSEH TusNEAl2ei7yUOh4uKSZ+jy0tMFD6YHliSbKbeK7RFntejPMu0DCfzLg59uDPsZCyO61 1QAg== X-Forwarded-Encrypted: i=1; AJvYcCWJBEeRnEVafqRnoPWV8KCh5U56tYUZtm7IseoKgVwpy6A0V2LrkD5WDZCOHaylXeOiugIWyh4XJx/zMtUB6XKIjCg= X-Gm-Message-State: AOJu0YxOqP6jY7xYBhsyA74PQ07VgbPHYeJqPTc+G/wb2lPcIJviWS4S wG256IeGUT61lH2Mt0Xcup16ub9s2GW74AHjF7LmwMpGQlwkBK9c9z2YCZb7mU8kem/iNEruOT3 suCVasI+jXjgy6ziTrST5mZqKO0I= X-Google-Smtp-Source: AGHT+IEkpVS/KLRMQPnw9X+wbLmx8m3CphQHdqOKfKZj2lOQX8oXUjoSzV2wjU0pHsir6K65f5qJDRQfuUb9ylYVQPU= X-Received: by 2002:a05:6102:1613:b0:471:e1cd:8c35 with SMTP id cu19-20020a056102161300b00471e1cd8c35mr421404vsb.19.1708804259619; Sat, 24 Feb 2024 11:50:59 -0800 (PST) MIME-Version: 1.0 References: <20240223041550.77157-1-21cnbao@gmail.com> <20240224190255.45616-1-sj@kernel.org> In-Reply-To: <20240224190255.45616-1-sj@kernel.org> From: Barry Song <21cnbao@gmail.com> Date: Sun, 25 Feb 2024 03:50:48 +0800 Message-ID: Subject: Re: [PATCH RFC] mm: madvise: pageout: ignore references rather than clearing young To: SeongJae Park Cc: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 86D57140007 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: xce7kyzkkgoqg6ith1iob6hwkobnxq9g X-HE-Tag: 1708804260-25135 X-HE-Meta: U2FsdGVkX1/Ru8ka1xQMiYzeBO9g9clpTyH7hHN9hnS/nFVChZkQvHIxBOT8Y1S/kWkwkwhIp6uqoAdP/Bb306nFXo465lucRUxKez2q6CXiaszADnPtzodpexLX+lCJO4XDq6FBykbag9c6iPEnhiVUCO8dDVftAgEm/00U90lpT2S0vzRZj1WU5SRWaEyMU6YgmS7o3JIOkjBDxEsMsb0uWfGvwopx17Bf1Iu19Xw5oWRRsWKF1IlZ7Um9cq5ml7im8zjUaVVh1+ADb5lqvrwM5HW9BOVbJ8FXyqfzcBUZjWdc/6vNzeoz99Ni6Q/MdPJ2GdkPD1KVLk64W9AsdOTEterpKkMNI6oq+dcFTx95sY3LLA6TGKVf6Q9pm/i5B5fifG3qc3q223vWcqFO/ZSM4PQYN2WF+zOt5rNykkdEUXD17H/wZPJ7q9pr/KRCuFLdN9ZWzbHDFBXZQ4WfS7n+Mac4vfwXvenYZ0eOH3CrOuXwBSUdALCzeZE6Zf/3RoX51qpQlFI92lKcKeCDzDlx1/pnudUcHKs4PFaBffffSZPeUbRxQBk7oM/dLriBctsM45MqBUfTi2PNdWq+8bRuKbUVfkcobGrxKm2l2Xb1rdYHZgMGKUITZg933IPZbKR43AaKhLU3rtL+1Yr5iOub6HQwCT1ZQd5rlIg9vJhMGSDKe4/VXaC0Xk0Glqny0ts2kYw9WR2LX/aJgD5FMAU/WtLJvMHBvQKTGmkovUmKyNJdydkW+tYXmJ7cwYJh0SL5DNy7v4PGxo3A82XplJztQAasxAnnvVB2IAJwXidVuYqJ9oFjqZZyNhXw1e5pscSQKueQ8yEi/FhCp5Is1tE6ghx/5cF5pOvsgWWQ2VT3qAwfTgV95oZ6nAouQBlWwaKiNndottfOmSPqGRYu0UKYrcXHELI8xYlG4hni0gcAZvYL2YiWOOlgAk+Hm1FzkJORiqpsFiEiiHzyIcz k6iEgB0r wjx+jr3TbJWa8wSIOHsfa5kK0J30oNZy7KQsvTUGtpjWiXFzr9J0+cEQwVAHKH/WQTM1BosVvtiFZauoJiTXxy20gUhxqKA3JYOf+tl39hFmQJP//zB8uHv4tDRoIjmwsPaIBzxovhwBDjtacHNrlN8n97BI5L1XDau2k1pTi8cD5b+SjovshaRLk7F0QY/UZXkSQm9no+HhxX4BtbJVFxdAzEPzYSsOAgaVcmrYYACgTDi3IyRcb+Dey7JFel3nZt8w4dHliqem0BGDuOS68LrxHMtQRGkUUz4MI+kjv7fBF+WmrHYZeBYd4WZ2E5NCQwKq9Xzhi/8ZCeAdHLIq3wM5hnRzxW4Y4khmnfYi4KkJa1m2bwp0B37y6xil7826WWsyaTyHIPwgEUcotaWH55oMVcw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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, Feb 25, 2024 at 3:02=E2=80=AFAM 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, t= he > page granularity re-check of the access could be helpful. So I concern i= f 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-eff= ort. 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 no= t that > important. > > Hence I think the cons of the behavioral change might outweigh the pros o= f 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 access= es 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. > > > > > #define PGSIZE 4096 > > main() > > { > > int i; > > #define SIZE 512*1024*1024 > > volatile long *p =3D mmap(NULL, SIZE, PROT_READ | PROT_WRITE, > > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > > > > for (i =3D 0; i < SIZE/sizeof(long); i +=3D PGSIZE / sizeof(long)= ) > > p[i] =3D 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 Barry