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 07BDBC5321D for ; Tue, 27 Aug 2024 02:21:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5793E6B0089; Mon, 26 Aug 2024 22:21:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49F966B0093; Mon, 26 Aug 2024 22:21:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F0ED6B008C; Mon, 26 Aug 2024 22:21:58 -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 10ABA6B0089 for ; Mon, 26 Aug 2024 22:21:58 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A839840FE4 for ; Tue, 27 Aug 2024 02:21:57 +0000 (UTC) X-FDA: 82496425074.10.2975D0B Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf17.hostedemail.com (Postfix) with ESMTP id E0CB84000C for ; Tue, 27 Aug 2024 02:21:54 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RSurEXb7; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 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=1724725295; 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=/GXXn2FFJ/DjUCmJ68K445AX+nSevjwrVhmRcNlSs/g=; b=BaM60qArOiBTxRz9MnJC9rVIIAJnEht6SsEbfJrtRI7K5lMTn2bq2sevFmmxEaOb+CnMBU jRcpF0UlYxOZB5JEXuJtlwcNgMyDWQc6wzYJpscGAgLp3LYe+MrbCfrU87ZrqMmirN7t+K sLkAwdJCuvrHVXFm2ftKzKbVoNA7aRU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RSurEXb7; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724725295; a=rsa-sha256; cv=none; b=Fq/kH5iW3y54j8bgNsp5bIJe+N3NAewPV46BCNAfrYDDz/X0lxzoJcCSM+zcXPm8mMD5TQ bJ0np0AZNv+oM0wbmQ2ikdtL5RtZ1oXWOcfwMKy/c2UklFdYLSeAgMtYLgUm7FrOZKdSUs trHD3dzMVst0BlRR1aXjv+RB+RlZu/I= Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4fd117e0008so1375692e0c.3 for ; Mon, 26 Aug 2024 19:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724725314; x=1725330114; 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=/GXXn2FFJ/DjUCmJ68K445AX+nSevjwrVhmRcNlSs/g=; b=RSurEXb7y8si29bxAIPMTzK+gFioFx6p5IIXkWdFu82W1AEIhw/hqurewqoZdYR8EE rwg2JWQZuUFmmtdLfMbQqSq6no+rnvGWUxj465EjA385TiTXgiXmLP1+CLERxabgQdfd RgaF70pPUXWaMPByWzK1zE1a1tDDm1V8b2tAa4FFwwmHxnWtOXxSRYAQIaQxEH1aGd6v JoUuVySXbF3jE8KIgyhfeJDiQGU3/0D4iDF8GhLv37zJoZXx+N0Pyivl4J8PWhu0kc9l da+V6F8CQNM7tH6a0FhVuQOId9rtaVaELkXb6mHSB1kEnjTo3XwFVemSUe2M97Zv0trv xJAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724725314; x=1725330114; 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=/GXXn2FFJ/DjUCmJ68K445AX+nSevjwrVhmRcNlSs/g=; b=YG3iWNHEPHYMRJGgnSk3WJVVJmyPj26wzk4pThlwGFZcxlw3dQFIz+ecqH+exIGupk vgmEOOmen9rJZHFoH1F0jplhpq1PBI5SoDtVIjd9xPfNmWm5f6M+W+PTk7F5QJTpRnaN 88x0FMncCz2QOanP4PStBvvCJfeuMbxVVy5DazlLXkBvmMKhIIT72JO4n4cPNu4/s6sf VtD+kX+hRmW+9MPpjTPEFOmcQ9/cei7ivLz6W6d/o+hq50Yi6tir3DJr6siO2eZaIkmx KPLTqRbgcex9iakHVgFx9xO0LCp7WHBO7684kKjlyTGY673xDkf75+HRL4AWneZ2oIU4 MjVw== X-Forwarded-Encrypted: i=1; AJvYcCVX/IMoKXIlTsKtK+oMIB55djDhucORnOP8ud+/JyVw1+kiRuW7UQTaK4HRRg1ityII86utCzvYKw==@kvack.org X-Gm-Message-State: AOJu0YxzTp0+aB6ppwYCOC9caeSPGlz/cdbOkG1I/DRbTSYu+1Mr/EoI 1AJa7zgFJYDWySiJorIMOxaNLP/IhjpOkwXEadCycyXSzoSCozeM/NyQmOibFEOoMakP1mQD6Sc XZQda24EJUngkS7fHNjp0P3jjMjY= X-Google-Smtp-Source: AGHT+IFGRvVJKZzhsvIzEksY/0kJq2esAYdnR/hYST+sLJhvuxKLuA+bnUtkW1bRSeHDHtzpNDWBtSfoHkRl0ef8st0= X-Received: by 2002:a05:6122:2a13:b0:4fc:e3c2:2c71 with SMTP id 71dfb90a1353d-4fed5d674bcmr1868769e0c.2.1724725313688; Mon, 26 Aug 2024 19:21:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 27 Aug 2024 14:21:42 +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-Rspam-User: X-Stat-Signature: hj4qee159xrg8ybenmpg511w49ekg5py X-Rspamd-Queue-Id: E0CB84000C X-Rspamd-Server: rspam11 X-HE-Tag: 1724725314-724404 X-HE-Meta: U2FsdGVkX1+PXlIwkIdRU2c9g3CQSb0qJx1jsfn7iT3BhtYvOWvDTd6F+D+sDeLOvxpr2tXclltuW0XfueNW4gpJdrBoHoHbw6+fb9FWZ2Bf5iahcFbMZv4RRA64iaB/qB/wRzOGC3rTCXqnUQGRjz9oxUrVYFPyJB3WSkhQqaxWc6vnRvSTof/gQfbjyXuPrmzqptkWi3F/W9tDEABLsZFPF8ZcQsWpR+d/o2rZVUHz3EnhO7Xw+WgQtT8aVwB7m8ecw9jP5WUmPDKu6gxE2kTkhGQLSFUZ0WdJiM5g49bfczwFMriJNEIBgEY+PXVoGPvdktlcpcuy6oqunh9IdQDzFIaLEXn/vdt5M98+6FGVfSzaPeDUIFoRC2qfKXPyOldchIFs8hWMMx7g84lbCECZ8DyJcgYZElJ2KEP/A7BZilG4lPLUfVnk42y3olEyPqGdNoBgb9mPIIlbpfR5i7Ee+Ar/GqHyiACKAfjcYh2IQX60pMjKgJaLsJtitdGyl9PCRZDoGqLhVnzUbomKiSdxWjfz9h53Sg8fv9OHIdHrGbNHiW/vjY34Lt0eyF5i2ICyyFA/KLD++qK1sNgd+GrAYjL/LpDJOBG1o7EEnpt+mLicjk0+p3EIIM5ysMxA9BPV7w8cZf5ANgHofe9oSbVYcoRi8cSw6Xvs4CnWitF0sy3iallZ257gnx4SLMnnwvJ/B1pqAt1YkH6hjTX2c0Z8rldvqQZYemM8ExeNed8KZkZa9w2MXTbD4qE8Q8eJIkQKl4EQxT+tNeSWpiYdZOQiMSrbB9/833Q+Z4LPK6nfJIFwuy/5XxhD/MSz7p8T63RM2cbwYEA22mdj2vbTp2gJ+NzI2lmEauRWokmtGQpBL8YF1Cn+33UvEQ9/fhAIQ7C5OGRwUbLMaYyRIntDvH9y+msZZcJp+X1fbp6i5RIneqc0kPU6SzQtIV5OrdHsBszdo0Ksa7tDVf0rsx3 XEDLecfA QFbe/B2bs7LI+4WFl83UVoBmxEuwBYEpzl1nFR/js9Pn1C2od1QXEBFgttHpu/1xp7pPsUaM4vbYwgAXuAvDF8okGlcVfP2lCkziRQ8wGzRjDTI6VljC9VzkTscjZdpbhZC2t2eLuLaf3ERSzuBrYqUOEHh5eUbJckuhXbNpVvM7EIWW6wM8tGftipcspmcceecBxyIq69POJu+wq8OnVEFdI89arv7RrTcn1Fx4sB0ndV7mFxcQdeT6ljOYu0VqocDb67YP/g/8ZuV+P+P7xxaq2PYlhzXdKlij2xgA01uFAxvOVrNJvfSZHm2dL78yoZn7Q5wAu/vihF83ysI+aKhzr3+bMLKReSOJhdxtvpMFjCgz8eWRQuMnKWDVKjn3GTTKLPBiCDuYNAT0NUrs7M9pv7cvOModE0LiOH9skkyIYjDWqFu4oj2cctB3nOXNRgQjXw8MKjt3DBuypqpXftkMiVEM87l3bw+PaDzlQf8w+AcHyB1hXSCiGKjTTfO8mpgyb X-Bogosity: Ham, tests=bogofilter, spamicity=0.001675, 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 12:12=E2=80=AFPM Lokesh Gidra wrote: > > On Mon, Aug 26, 2024 at 12:55=E2=80=AFPM Barry Song <21cnbao@gmail.com> w= rote: > > > > 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.c= om> 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 lr= u_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-f= ree folio and > > > > > > > reduces the impact on file refault. > > > > > > > > > > > > This has been discussed when MADV_FREE was introduced. The ques= tion was > > > > > > whether this memory has a lower priority than other inactive me= mory that > > > > > > 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. > > > > > > > > > Hi Lokesh, > > Thanks! > > > > > > > The priority of this memory compared to other inactive memory tha= t has been > > > > > marked for a longer time likely depends on the user's expectation= s - How 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 i= ncreases the > > > > > likelihood of packing the file LRU and reduces the chances of rec= laiming > > > > > anonymous memory, which could result in more file re-faults while= helping > > > > > 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 u= sual > > total_size for a phone with memory pressure by running multiple apps an= d 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 On my phone, I am seeing a VMA named "dalvik-main space", its virtual address is 0x14000000-0x34000000 and its size is 0x20000000 (512MB). I guess this is exactly the ART heap we are talking about? > used. Typical heap usage is 50MB to 250MB. But as I said, not all of Thank you! Considering we might have dozens of apps running in the background and foreground, will the total size of the ART heaps on a phone still be large? > it is MADV_FREE'ed. Only those pages which are freed after GC > compaction are. Are you saying that some memory in the ART heap is marked with MADV_DONTNEED instead of MADV_FREE? If so, when did this happen? Alternatively, is my understanding incorrect and you are referring to memor= y that is neither MADV_DONTNEED nor MADV_FREE? > > > > > > > > > > I am really curious why art guys have moved to MADV_FREE if we ha= ve > > > > > an approach to reach them. > > > > > > Honestly, it makes little sense as a user that calling MADV_FREE on a= n > > > 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 l= azyfree > > 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? > > > 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. Thanks for clarification! I'd also like to collect some performance data wi= th this patch. > > > > > > > > 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