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 79E57C5321E for ; Mon, 26 Aug 2024 16:37:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA7186B0082; Mon, 26 Aug 2024 12:37:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E56DF6B0085; Mon, 26 Aug 2024 12:37:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1EAB6B0088; Mon, 26 Aug 2024 12:37:37 -0400 (EDT) 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 B27BF6B0082 for ; Mon, 26 Aug 2024 12:37:37 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5D559161039 for ; Mon, 26 Aug 2024 16:37:37 +0000 (UTC) X-FDA: 82494952554.22.91ABBF0 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf17.hostedemail.com (Postfix) with ESMTP id 5E54540008 for ; Mon, 26 Aug 2024 16:37:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=a6siw7Zr; spf=pass (imf17.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=lokeshgidra@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724690212; a=rsa-sha256; cv=none; b=kDiQp5s9RAscpQuVJ2hduvgNFxpUGJqThJnUV6jfAeXvKFa5dSo0F7VOeDU0NLXUqwxL94 gvrficAQS4fogjvoLQO7KN8re+cS7p7KG+BxVdCT8gL2jr6Zrf/aTvxn9g2YQ5Z874u3fr pE+ehIlQLXL//XxdPoLBUddVL70rvqI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=a6siw7Zr; spf=pass (imf17.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=lokeshgidra@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724690212; 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=6SOwwEak8HNUtFdi6w1IR3Fh7ui0CdwihCwbP/+t5tk=; b=AJDbXNq+NlRgmOCCr93sXzwl6DgCFRjyviaRYW3oOjGBvc81uhspCV/3rQ1DE0DYh9WAHl lE5Aw8mTO91U0L/B2ytMo0GH3lTitJBCGk1zY5DnclIQYxHdzHJx6ecj0pO5hxhTtvG7tf NbqWS3u+PA1MMsvjM5g8PBR56GGD0aU= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-201fed75b38so390655ad.1 for ; Mon, 26 Aug 2024 09:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724690254; x=1725295054; 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=6SOwwEak8HNUtFdi6w1IR3Fh7ui0CdwihCwbP/+t5tk=; b=a6siw7ZrFFaGnOdb6Oa3DTHproYxAeh9ZlsaeV4YHcWTXNFqn1OB4W/w9kc09Go4sx Jyof90hs1C/7X5ZIIhryFN/NDQD1va+O4+awNUyYgH5ljDPKXbn8I0W/JcYdAv1JOjQZ +HnUPnaWqgdBDww/6FxNgLZDkbqhFdeOevPMEPDsC+lCxtgws1A7ucvGD44huu+4GJTj +BtKpuS9UAWVnwzzFuSQ6LG2o4Nafi5PlvninSItbdeCwkQyagEUUtSnBq44DnLnmWAF T7airjp5VaggbC0erK36/CLDByaS9oq1YlIgQNgpSbcljNd648AAgKpw8ekuZdCYulyF xJ1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724690254; x=1725295054; 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=6SOwwEak8HNUtFdi6w1IR3Fh7ui0CdwihCwbP/+t5tk=; b=v9w05E68tMhGxb3ec6Qx4uziNXZuy8rqRR2TbHyfMoAYJtaRKM6n/TqwUzRogiM0Wm JoxXhYYjhIeiPcXsIZPMU5UaAozg2NJsxIQ39uvu/dllt02Pp+z8qYNNmEVrwjyKNER8 57d9bCgdOy9Cfzc9kYs78a3MEicQFQzlS0O/ISiHZE0HY9U5bsJXZl9CX0QMjwwN7D8H xjhUzQY9sko+4SO/VwZElZsTsNxa0QEW5LQFFwZpUXonRTM5Yj57xKGUEPft+30DADuk 7VSZA33XZaUWX5vFpOF1p8hYaq6bauQ/mN0d9/Z0m5VTiaewN5wof87/4NcalQUVsfsC aUww== X-Forwarded-Encrypted: i=1; AJvYcCXyVzih4Izs90d3d/qMLjiB4ayh47FnDcrD/OtM+E2pZJ8qyMlpC6QZHAbsXX4HmuK2lpFxP6YwVQ==@kvack.org X-Gm-Message-State: AOJu0Yxbk1LA+C9CHRD7KB9wlhbZLEF9YM5iHkLNFLv+MfYsd92Ac05I +L9DmxCe2Wrzkk7z6LkFv/e/nLt05h+qpkwkOGNLgCVcguS3gwIclhxZrI4yFaRGeLStB+c5Ojt FCqCeKJsvXNXrKEYh69qChf0wQf3tnvE9/Zdj X-Google-Smtp-Source: AGHT+IHjcvh47kOzCIEwZsibkgNOi6co7AgGvdigUdHRaQeq4Gqe/7kb6PEt73qK+dAQhNoKQrBZvRkORDCtN96cUK8= X-Received: by 2002:a17:902:e84d:b0:1f9:d111:8a1e with SMTP id d9443c01a7336-203b2c4867amr5232205ad.26.1724690253624; Mon, 26 Aug 2024 09:37:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lokesh Gidra Date: Mon, 26 Aug 2024 09:37:22 -0700 Message-ID: Subject: Re: [PATCH v2] mm: add lazyfree folio to lru tail To: Suren Baghdasaryan , Nicolas Geoffray Cc: Barry Song <21cnbao@gmail.com>, Michal Hocko , gaoxu , Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Shaohua Li , yipengxiang , fengbaopeng , Kalesh Singh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: js1xk4brognz5mf9xrqsq8ui4aphsdyx X-Rspamd-Queue-Id: 5E54540008 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724690255-550027 X-HE-Meta: U2FsdGVkX19+r5gp3h28GpplXbDBQaTcglH5XcxfdZi+IofK9v6QBPNGZnB0dyehGpUW7JmxGAPVDvVgqPEguxz8MQxcFS3ZpN+VdMHo2gjJlPAampzQTmGFoRTHoF5aTDJjH02FsymneC50UAc+EI8hX11S/cBSqcMU2inAO+Z5b8E1PmU0iXn1rVBZdn8b4QnAlpHv09m9PBTkueeIFq8YuUX7Ib3XC0pB/0Pa0BGV9uzLbJIW70P3Yj187+hqhLeoCHOpw1PC9QX6wzZt1pQSQ1f0VbqImkoXe5VgwqbopOO+bMoHKXbMToXl1mnhZticoiotDXhcDeDo0QK5LOQHuKIdBOa+IIswjAifteCoAsS1kttpJAaanbpTf6pxJ9WqnzbLUNnSCj2vqnDYvYt+z+P0Ytu75Pm6GnTUyfTgX56x5koizQr8ttXh72b/3UmH2pH11dn31P2qlD6uA+6xKRErN6+3ltCAube5TrzjpQkjrkpmxXjjEj/8LhJixSsVEjmxnZ6YbwPhzgM5Sd9ivYnq9oe2d0W2uah7Fvi6ElA1+hQS/ZY87GYoWiO65VP2fY7oSKTEaICxTIlVuQSgFCjZyEaJxyR7fyeGQPtx5ZvU4FxF1sAfo9DBl5Xm8CTro3cTfbEygfIIihYEytJN1vo+MuiWAkfl5vgDxxza3hkbZfKrDjE741xsAF3besvorBgc1ONyok3oH/c5mfVE/eGdxMX+UnLy0FLuW2uupP7FFswEaoMmkECxrtH+Hl8DIpPuAZXxSh86isawWm80az+BO3P30P2Uj3ySKdq7s2cNCEISvMfYdDJ4aYGb/RcWxh3dpvIxejJbX0SkZxY362Fs5p1dWblzTYClBQM8tomhkdN15NKjLWav1Dh7efDZVONf0VgiSB5KZKyRBMo4LGLqdM1OuR9xlFDo4JazjGrpfBogZfZsCbjC50xl9vzB+QNguOymQ/vR9Eg LzIvmpXX GsUniddDIhI1/oInQUH5pFB4q8NgP9QfsAI6SLDkvAM/qDHItMm1MgzXR/cFg4BNXiLgtkGZwA9E8iv4FC3dSusxn7WaQS+RIMxqnmMgU/+12sngqbSNp2AJKSr6wF2fgAUhMo0KG9ATDLrd3qsUNAxw4qimxWY/DQsEgaOYkaydFPwBNnWjsZVY2eF4iDo8Xnj0/J+YjU76Lj9IVBHsY+X/9ZzNYStJkNxNBoBQKrGChtStuQtOlam0cBKLpUuv/9YDVaIebdarESNioOwfYZ/LJ0YruTjj+8DM6OP3VUNvdu7K41cRNz4XV/0oBRJk6vUSSSitJLT/XS4HtTED42tKEAQRyGYdM/g9u2OtT+oWia+rxfZsgh8N+8Yrpg6sM/8Rv 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: Thanks Suren for looping in On Fri, Aug 23, 2024 at 4:39=E2=80=AFPM Suren Baghdasaryan wrote: > > On Wed, Aug 21, 2024 at 2:47=E2=80=AFPM Barry Song <21cnbao@gmail.com> wr= ote: > > > > On Wed, Aug 21, 2024 at 8:46=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Fri 16-08-24 07:48:01, gaoxu wrote: > > > > Replace lruvec_add_folio with lruvec_add_folio_tail in the lru_lazy= free_fn: > > > > 1. The lazy-free folio is added to the LRU_INACTIVE_FILE list. If i= t's > > > > moved to the LRU tail, it allows for faster release lazy-free fo= lio and > > > > reduces the impact on file refault. > > > > > > This has been discussed when MADV_FREE was introduced. The question w= as > > > whether this memory has a lower priority than other inactive memory t= hat > > > has been marked that way longer ago. Also consider several MADV_FREE > > > users should they be LIFO from the reclaim POV? Thinking from the user's perspective, it seems to me that FIFO within MADV_FREE'ed pages makes more sense. As a user I expect the longer a MADV_FREE'ed page hasn't been touched, the chances are higher that it may not be around anymore. > > > > The priority of this memory compared to other inactive memory that has = been > > marked for a longer time likely depends on the user's expectations - Ho= w soon > > do users expect MADV_FREE to be reclaimed compared with old file folios= . > > > > art guys moved to MADV_FREE from MADV_DONTNEED without any > > useful performance data and reason in the changelog: > > https://android-review.googlesource.com/c/platform/art/+/2633132 > > > > Since art is the Android Java heap, it can be quite large. This increas= es the > > likelihood of packing the file LRU and reduces the chances of reclaimin= g > > anonymous memory, which could result in more file re-faults while helpi= ng > > anonymous folio persist longer in memory. Individual heaps of android apps are not big, and even in there we don't call MADV_FREE on the entire heap. > > > > I am really curious why art guys have moved to MADV_FREE if we have > > an approach to reach them. Honestly, it makes little sense as a user that calling MADV_FREE on an anonymous mapping will impact file LRU. That was never the intention with our ART change. >From our perspective, once a set of pages are MADV_FREE'ed, they are like a page-cache. It gives an opportunity, without hurting memory use, to avoid overhead of page-faults, which happen frequently after GC is done on running apps. IMHO, within LRU_INACTIVE_FILE, MADV_FREE'ed pages should be prioritized for reclamation over file ones. > > Adding Lokesh. > Lokesh, could you please comment on the reasoning behind the above > mentioned change? Adding Nicolas as well, in case he wants to add something. > > > > > > > > > -- > > > Michal Hocko > > > SUSE Labs > > > > > > > Thanks > > Barry