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 9098AC5472E for ; Mon, 26 Aug 2024 19:55:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23FA16B0083; Mon, 26 Aug 2024 15:55:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EEF76B0085; Mon, 26 Aug 2024 15:55:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DE446B0088; Mon, 26 Aug 2024 15:55:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E4DDE6B0083 for ; Mon, 26 Aug 2024 15:55:08 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6F2FF1A12E6 for ; Mon, 26 Aug 2024 19:55:08 +0000 (UTC) X-FDA: 82495450296.17.22B42A2 Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf07.hostedemail.com (Postfix) with ESMTP id AE16E40026 for ; Mon, 26 Aug 2024 19:55:05 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Pnuhhb9D; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724702042; a=rsa-sha256; cv=none; b=Fb0U7J2jhUFfqG2eXXWhb/UxxGJGjZaMrkfq7BMV+8CYlJvqXLzpNurLUUjMNmFS73BXrY wLl1NYNm7V8MLk63lyg0VMVNMXYYafHIfhV55SjgSNlEBIRbXunELQt9qUT6o1x1bHVFV3 W7TAcpHt2RyWucBo1c1OeHeYJOkAH9M= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Pnuhhb9D; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724702042; 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=6lvqcUUG2VACthL4mM2/GjAp0wLyM/ulL6auuz/aKWo=; b=QR2bS/PRy2iIZj6Y1KZ/XKXFzge9YZSJTJxQ7c1J03XFNPVn5SErnGwPPmauM+NGNIog+V 4xfEHjL6zSeWTK60h9YZS5xHO8NG8wE1F3BqvAWAZ3rBbhXRgnjWbhQrIRfCxoG1CzG4Y+ 6s478XAZ+bGi3JTAC1cWlnQKVhzRbpI= Received: by mail-vk1-f171.google.com with SMTP id 71dfb90a1353d-4fe9f618665so838579e0c.1 for ; Mon, 26 Aug 2024 12:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724702105; x=1725306905; 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=6lvqcUUG2VACthL4mM2/GjAp0wLyM/ulL6auuz/aKWo=; b=Pnuhhb9DMrt5Qt3XiXwrPDL50Rdoa4bmbRKmWy5ukXDLlpZ1xKsnO4sv8o7JF5zhV7 oHBaMxC2WrMuKDotqpU+DVn+COYHmQOZBmD/RIClulX4oyPdo9MFgwLhOgnyfm5OqG+I r8hezCydkQ/d0luzr+rxiYS62btTi/BbHeOxmRiUe0ujA5qV8SDB+piMIb6SyNtkNpwi 3lDcW2dOzGiSFOd00G6ioPzUNQ6yL2QYRt0ID5GsFtHjTlgbrufcEVHiBiB0OtuROQVR 8UJuiuuavOQcBbjlEGGQlbuNa7AVsjMOeB7vn64foBHDdcKQ2SaC4IQ8T0O+cZt58C5N eCWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724702105; x=1725306905; 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=6lvqcUUG2VACthL4mM2/GjAp0wLyM/ulL6auuz/aKWo=; b=mnw15bktucnCFEIqeiYjh3xPo6HQ6kesgYZ9UWMbZ8xhQJ2peVPi64VQCax3rHVVgY VMJmXtvDea7fhvmgGMS0Is6GFb9uQIumCRIV5555apuqqmJbU0QHxMpKGxTBDomNd1KW zu5RwHne7wlSlcD5s31hvxmlGADXLpYSC3KyVEywjvXDKBi9PYGw8fsJptaxL9tKdKYE oLDeQ+hklMhst8lnfwt9eg/3Z9CZ60u9LktL9HominpYac7ea7DfrHIjayWBZ6lLPZQO lrW+xxGS6J4/LPI8nash1+vvUds0LBE0tNWk/mUKEP1bOZjibm4yVUYyRfJO6ZlJPrOa bziw== X-Forwarded-Encrypted: i=1; AJvYcCVJFyeKSoVVVdnHO27vFZm6IXHG6uptN7XlcAkSeC8E2/8YFEuZ/vqwzNbxIa76iPFVCjY6PwBWow==@kvack.org X-Gm-Message-State: AOJu0YxEOOlRq6ou5VM2m9Y4Jrip0188a7W2KHf/RL2P15fK8G+tAjYW Izkq4nM4v6SdYjJgEHa8nC1H+//VGKOHhuhOVO1NLpocwfTKWwMp0jDw5hAv/+qQ9dXg2jN3I8Y xGIjkt0pUnzjCB0ZOzEFxGGCCk4Y= X-Google-Smtp-Source: AGHT+IHwPN+032XqzmoIu+B1HBK8b/v//3b8UQegfRNZi7W6W0C5NE/aG85RhBHq2CFB5Xx6WoFJlkXqCXAO0y87GOg= X-Received: by 2002:a05:6122:2919:b0:4eb:12da:14c7 with SMTP id 71dfb90a1353d-4fed5daef35mr977467e0c.6.1724702104613; Mon, 26 Aug 2024 12:55:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 27 Aug 2024 07:54:53 +1200 Message-ID: Subject: Re: [PATCH v2] mm: add lazyfree folio to lru tail To: Lokesh Gidra Cc: Suren Baghdasaryan , Nicolas Geoffray , 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-Rspamd-Queue-Id: AE16E40026 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 5ea5m1raag6aq4hwneyueborbmfgiixa X-HE-Tag: 1724702105-178643 X-HE-Meta: U2FsdGVkX1/TPQ0C8SYhP5yimKTz5ksdo/pgcHQcv0i2Op3Lw2hgtq1JlO8r249z3W9we/Yg+azGbPJigEg84WYHezbWwrfRupEteYxbUzqV0FE3pbm2i+bk6K3J5aK+kf5lebo22EiTtBZ/7xT5jvXXMQt/QeePqs7kOmFkMivRS8zPBQPlnNPwle5yi/Ewcs0Xik0602xqHijVnwbFhHcyIGAU6hLEoeD+hqfRvrDi71lt/O1VuItbrvnhWovJvBVZj/1lWQHRhmeFI70TdeqPL3fTeYaBGx28UJPQNo7tu6+Ypr79Tn94WTSE5mRIdNUFWpTPS8ceIwPRSMaiK/f9jl6JUCqLose1eXg/z1MF5/CAL70S7yMEabdPNPaXYV+ja02kcZHc1QEjHpO0kywexGKR6tXewWdQ4ec92aA/VgCLMp2l/26pzGjh6P/55jI2eL7rponQ2Baiflboo74tofPkuc1X4X+cWj1a59HoocLXkOuo4OOem+aqYbKib75Mq3uiaVhO4DDv5kTDsWowjsboRnXvVfSGfJq2lQDEUjHeJ2JxU0GRTmjXwoGdS/Jrw3qxpJHzNEpRhPfnHfEbxoqUPf0cnyHL+WiNaIWtb7++77b9/QvNrWgxgEMSseqm4bPPrNs1XtuS4zuMf4vPEhpo9YRcqZXS6fAuAlbOVJuVh5ItA9npbnh16dkDXQ/q9wxf2zGKkUH8MbZVQEudSxyEI3ltnezt2URkOqpkMkRuMwQZPf9lHQcAyz5hTIN7x2XblZAG6APbJWQAtbZkqyjaBA4YGkNH877kUaZGUlHOfsO443jOU+iX1EgkoaGvMSWBjOI951qH3Thw53Hv2oNowYvNhVspW+otExP0ZFOYlL2Xt2+cGQvTSDhuWHK5ZHRgDPbcjQUT9XCTuyvtyRkvaInAvWRLsLCHj5mrhBOhRA1oyq0VSwp9brGsGXl7LCnqg1pbhlZ8Pzt c0tgneVI hQNTfS2BwTcMuHAJRR90A4T+sDdjhblVY3BKZKMbQgB2nSMH/mdTvziRiniglM6Q/VXx7AOkz6crI/+WcRDaxTydDyOpJfCBHhEl4tsvzOe6IoWBPUpQ+M/ZXSz47HDMs3EXwOOyjGgXURpnwKlCx4jf2u6zT0YbEfkdEXpms8KKKPFuTjKx5MjlhBe6a7i8qs687j06/FC2eyLwO5tNKbN3eZPBO1gTkaELCkbVQr3KWMlARB2WId981EwtR3l99XIhl+meAz2Li+HysS5GGX5ILiRxD62Rh6Z0f/f+fSP+MOkMQy2V8mDcGgEv+dKkcMmpDDALvxUI7TxUu2WYv+CICfTMctLuA2la1n2SyAKyDzp3egWY+qwWfNT49umwhIvkqzVNCiNd+TYCvEpXDFO9bYrg32GdQamJfh7TMaK+qxaBDxweVlW6HEx6o4JULGhFOiGCLKmfOBRF+9sO2K6kEpB46cmS6qOlPe+4XykWRP9JTNgxTnKh4VvH91kdjqlCo X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, 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 Tue, Aug 27, 2024 at 4:37=E2=80=AFAM Lokesh Gidra wrote: > > 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> = wrote: > > > > > > 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_la= zyfree_fn: > > > > > 1. The lazy-free folio is added to the LRU_INACTIVE_FILE list. If= it's > > > > > moved to the LRU tail, it allows for faster release lazy-free = folio and > > > > > reduces the impact on file refault. > > > > > > > > This has been discussed when MADV_FREE was introduced. The question= was > > > > whether this memory has a lower priority than other inactive memory= that > > > > has been marked that way longer ago. Also consider several MADV_FRE= E > > > > 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. > > > Hi Lokesh, Thanks! > > > The priority of this memory compared to other inactive memory that ha= s been > > > marked for a longer time likely depends on the user's expectations - = How soon > > > do users expect MADV_FREE to be reclaimed compared with old file foli= os. > > > > > > 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 incre= ases the > > > likelihood of packing the file LRU and reduces the chances of reclaim= ing > > > anonymous memory, which could result in more file re-faults while hel= ping > > > 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. How do you define "Individual heaps of android apps", do you know the usual total_size for a phone with memory pressure by running multiple apps and ho= w much for each app? > > > > > > 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. > This is just how MADV_FREE is implemented in the kernel, this kind of lazyf= ree anon folios are moved to file but *NOT* anon LRU. > 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. This is exactly what this patch is doing, putting lazyfree anon folios to the tail of file LRU so that they can be reclaimed earlier than file folios. But the question is: is the requirement "MADV_FREE'ed pages should be prioritized for reclamation over file ones" universally true for all other non-Android users? > > > > 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