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 E2A66C5472C for ; Tue, 27 Aug 2024 00:12:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 682D86B0099; Mon, 26 Aug 2024 20:12:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6329A6B009A; Mon, 26 Aug 2024 20:12:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FA466B009C; Mon, 26 Aug 2024 20:12:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 30C2B6B0099 for ; Mon, 26 Aug 2024 20:12:24 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B27EE1C503A for ; Tue, 27 Aug 2024 00:12:23 +0000 (UTC) X-FDA: 82496098566.13.E31440B Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf19.hostedemail.com (Postfix) with ESMTP id EE5891A0004 for ; Tue, 27 Aug 2024 00:12:20 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AICr7ybP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724717471; a=rsa-sha256; cv=none; b=Wrh15Cjon9zZrU7BKpw8FruhkGaC18M751BUFMGTX89oRjwbXKquGmGoiO5h1Ni5UuaXB8 d8W+eoFlFF4tX3Qwb2xkq8wNB2tVBwD+CWeS1BCr+iRaO2byy//L5gOlLHISsouqh9JSFA kgwwBVaO1j4D8pwvAHwC1s/SxspCVCc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AICr7ybP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724717471; 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=fRGRwWPjttcmijXoKbPDYcfgfMfeDSyIylvYYsmrs9A=; b=q1+w3eJrd6WfljRdR6OdoTnhq5mXU470HvhD4FBSkt7rz8TzhZoyQeeSjnWnshI88hljvF UwYhGYOPHgJYRQuyqS86xdLS5uCCwxDmY/JuZPG7UbnmOefzW6EJin4ghqkwJoNhKEguH2 r5m3rz3WRGk1uXxYYZqwrnPHtEilaug= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-20353e5de9cso87335ad.0 for ; Mon, 26 Aug 2024 17:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724717539; x=1725322339; 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=fRGRwWPjttcmijXoKbPDYcfgfMfeDSyIylvYYsmrs9A=; b=AICr7ybPOOJaRci6vPfiGNeayc2dT/jd9IyizioadYYri0Rk7hL3ldUse+ycnVwBOq pWZkkSSZRE1RWh4thXyaL7gDS6JvqdNgyujMmHWo9XtBVCo3m6ufARXDaDN0mEZG1x3A E+5o9p6DaCvT0+zBjrrP9iSKYqcIkdzSK6cDajbnxgVQre+DCBJa13EeOpbNJNnQEC8g wrcXhAOf55mDuFLp+ewz69HmsKs9KRQgWlr3KmevASny/aZXpl/d/pR1bt2cDnvLO7BQ QZw2o8GEnYdnP/fBkxZQJsKUcSFteA2tLuqAiq21LgUabQ3+8/ccfu644XjmbtbBJDiu YvCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724717539; x=1725322339; 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=fRGRwWPjttcmijXoKbPDYcfgfMfeDSyIylvYYsmrs9A=; b=gPx9tMpHxHaQWCBGhiXVZMx6R8CnpERmKwYyb6Iy9xNhIbNkuvyUgW8sj2QXoXnAi9 MJXIC8BWRcvS+junu0+Xqbet6eS5qTzI+RJDZwIYrPBaAPuK4EX16HS1Ubnpq9i/VEsJ tZJ166qHT2dhMRjEesAruhdAbb5kFxi/9MkJW3oLx4ZWfpb8T0m0L1fs81tk8Fcdjbc1 7s7aSAEQ2A+nVkyRWssqMWIr9JLL/4N8gizJlNVuZKFuyBAyEE9krwRY5k+D2mlPIIqT EfetTA2FkCWXqpB1T9Pwt4g+5WuonGJh3Rhr7mf6Y95CODXTiHoUbIEr1y0S4XDMyNsG CTcA== X-Forwarded-Encrypted: i=1; AJvYcCV+7elxQscJ+5v6VWtry6JazCBiXSnKfugtc7ZRuQbmi9/UD/wPqO+Ie6qXymUNPEcY0Y3JbJT7yQ==@kvack.org X-Gm-Message-State: AOJu0YwuE16i6aHrDme0/NpprOrTTOqsNBJI0vCsKZsWz0bMRrXvxRiL wpwHkZMhDGidGHjvK1sO/dhrDOcaWeJjOQrECLu3iXgA3V0jZwHvF8yj9hj6VZkCzmtK0nqzD5v Q/EFizjo6UwVZiv2lTlj7zSMt5xlsCwZOmL5L X-Google-Smtp-Source: AGHT+IGznodxybhICLFyTDC60nAH6himwX8JRO9ziRWkiLzOyjSxsARmEkZbV137GLRdfgM2JznV2kVTKrUNVUoaS/8= X-Received: by 2002:a17:902:d346:b0:201:e2db:7bd1 with SMTP id d9443c01a7336-204e4fb64c3mr702385ad.19.1724717538983; Mon, 26 Aug 2024 17:12:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lokesh Gidra Date: Mon, 26 Aug 2024 17:12:07 -0700 Message-ID: Subject: Re: [PATCH v2] mm: add lazyfree folio to lru tail To: Barry Song <21cnbao@gmail.com> 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-Server: rspam12 X-Rspamd-Queue-Id: EE5891A0004 X-Stat-Signature: qt65jiwtjjxqtkh6f4dq1e8tw5ussa7o X-Rspam-User: X-HE-Tag: 1724717540-246607 X-HE-Meta: U2FsdGVkX18EDYO67CS3FvieeQYP6G0l7pSRRlZsoCHDgm8AHH388hX4Hg0fT58JwN/QjtBswmuB5M426jCLACYqO2TCWLGADUS9CFvPEoX4tTTZ40kNsArXhTXQiB3+9GPJM6gnQGyxLpWX06X0LYSMV8hwDkxJnQCqqvduP0b8kNtmwLSLA1NeDLaveo19bwuipapyh3EyN8E4U9ie3ZidJzMu39d9gfG2s6OBxZIWcR0bqF7h34M+EERxVXpv9CAQCS0DM0MN4/F4rdBe5KEO0zCdrbvh8fBPhc3CEzbrPCTNRBnGpAqVG+ba8t5IPYL+cjeQXFXrUvd9aliXXT8LE4ypJZR2kirwRQcjVobVSG+kS0iYCAV58K8+xXT0m6vr3oHWU5doBJ6cnX3qa4X3TeltdKVLmeoyy09IgI3jnmNJMQXOjIY6Molvy3uN2Pqn13K81VEIa7sKvp0pzDogXBAVqG3BApK2ft2LuEQq8CrZKHpL6YE2FVg78JvyOj25dc/LhlqxKozP2TnEuB7h39PfRGysEZWbzD6DcP+73VMyHA8kCHyjndzZdVloa+y9A86lmI+RSdBw16/l1UH40kK8Cdh3XA/ZMZibglERsL3hfl1p3BasgMVGnL1fIDkXHSRiREdX5fjHhQQ9fer8VLZI0LXGmNmlJJjEpkhakz0suEtP4pk0wbrqvMoGmC/pyCDIP3x11AqmT0cJQN+MIxUhlivqdN0XjjBptL6e93iT9ZFKo88VN4Td6ovkbG7e0I9l3w9Mc7Os0UQ4V8InwcBLDdZYBsJljHTr/lwIoH5ZgXm0Sr1hGo5/6hoPD76Ckvn0/TeID3xelzigaaoKwv4L9XKyzZTi388//Lb88zqjIDCaYNVMLgI9TyAwo0kW9ezbfkq48H54I83KHgHcK/BQwtcWrO2jjqwloQR3lIo8PYEZMBE8uwqMc3nkmsbop70bAGhTq5siPeO r/xtmOTE QZZt3Sr9IZzBeGCtbxy/a4oiBCwhKZAjtezIAIMqoP6RyrGxlbotyEqh6CmALZP5FNNmb7dQZ9sQzy22rJqDZfT40LFlCkme2YGyywsOK+0o0ba7xtGU460Rh+GKoMrmXaSSBv3oGIUM4DbMsSKZJ5fflAQKOmsgUX7znMJyFBj6JEDT7DbQqL2r5enzDe8EfNLsMbDzXO9io1GK2ciD8ZTG+HlH5Eh37wGKovCW1PYabh2TmcbDpersUDVqpjMZ/q1ohCVfMCsSAu9+MAl/09HbkuHf+G5d4LxKOaZcLmTwF1ZgnA+Xp7dPrn/gVeK32WjQiIPGF1MiYiZ0sQNBCwDYHtDizF5lRPE2xAg1uZhQE9Or3EQmFgDQ/+P3iBjV9f8we 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 Mon, Aug 26, 2024 at 12:55=E2=80=AFPM Barry Song <21cnbao@gmail.com> wro= te: > > 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_= lazyfree_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-fre= e folio and > > > > > > reduces the impact on file refault. > > > > > > > > > > This has been discussed when MADV_FREE was introduced. The questi= on was > > > > > whether this memory has a lower priority than other inactive memo= ry that > > > > > has been marked that way longer ago. Also consider several MADV_F= REE > > > > > 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 = has 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 fo= lios. > > > > > > > > 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 inc= reases the > > > > likelihood of packing the file LRU and reduces the chances of recla= iming > > > > anonymous memory, which could result in more file re-faults while h= elping > > > > 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 usu= al > total_size for a phone with memory pressure by running multiple apps and = how > much for each app? > Every app is a separate process and therefore has its own private ART heap. Those numbers that you are asking vary drastically. But here's what I can tell you: Max heap size for an app is 512MB typically. But it is rarely entirely used. Typical heap usage is 50MB to 250MB. But as I said, not all of it is MADV_FREE'ed. Only those pages which are freed after GC compaction are. > > > > > > > > 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 laz= yfree > 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 fo= r > all other non-Android users? > That's definitely an important question to get answered. But putting my users hat on again, by explicitly MADV_FREE'ing we ask for that behavior. IMHO, MADV_FREE'ed pages should be the first ones to be reclaimed on memory pressure. > > > > > > 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