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 D0D90CF9C5B for ; Mon, 23 Sep 2024 22:38:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 385DB6B007B; Mon, 23 Sep 2024 18:38:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 335616B0083; Mon, 23 Sep 2024 18:38:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D56F6B0085; Mon, 23 Sep 2024 18:38:53 -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 001546B007B for ; Mon, 23 Sep 2024 18:38:52 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 785E0815E6 for ; Mon, 23 Sep 2024 22:38:52 +0000 (UTC) X-FDA: 82597469304.10.6612792 Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by imf21.hostedemail.com (Postfix) with ESMTP id B268A1C0014 for ; Mon, 23 Sep 2024 22:38:49 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EB+fDhZX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727131042; a=rsa-sha256; cv=none; b=iBu8O3T6PbC/0nBUPByD5QdGmjPUPvh2o7AI8j6X2vG5eAGF5h6pUsaSY5AWrGsvBThQOn ssM9rNbgCW/lFmwACVagdfAWz+D/Q6QEd17v03pTbooEFOs9N2t9M1DwiPFuH+4bR0kPga lO+KCKi9cm2F9POT47dPcr9Bt9jeY5U= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EB+fDhZX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 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=1727131042; 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=ieQiIqp4mUc0jaqrAQ7oZWNURsFcF+oahPDsRs9kBnQ=; b=4oubMEu0g1+6qHlCIYB0wGvUoWGXi7+X+lbN6g3Iv8SSiJbA6+YRZWISPLomrch+g4q854 xA3VdL4CVzmvTHGDLhOczX7nbCSpNuKyPw2XsNW2E+9SYTBIQmXrDGobu3f5I/7rngQ/hT GZz+KqRg7wAjLWjOe06DFIDoEimZH50= Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-49bcfbc732eso1729568137.3 for ; Mon, 23 Sep 2024 15:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727131129; x=1727735929; 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=ieQiIqp4mUc0jaqrAQ7oZWNURsFcF+oahPDsRs9kBnQ=; b=EB+fDhZXeGxkufTy8DMEtPY1s+DF9aDHiJwLXIxyaRLrkDcFLoh2/5UD3bXN+JIukC RcsXuBHgjPcABcb7i4mUfmYAKpz4wn7HW7DoeMB8L6Hrzo9EALyZjZ2EQ2GJKpGeIN7p ONf3Vi6v//UN8hdaM7O14F4yCTkSpBaUJ0iGOBsialEUArK8N/0itVKbrb8TYebsro4I 3LtO0XRdegQXiIUAGWL60U/FL9Vt9hIekPPTCdFJO5pTuMNe3z1ldu0+EBqrMHnydDXo yrMyxCyu1rBdZraDHufCsn+yde9c0qcoc7qtcX1PAi8MzxYiUoLZYLrddq8cLthsLlM8 5Rsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727131129; x=1727735929; 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=ieQiIqp4mUc0jaqrAQ7oZWNURsFcF+oahPDsRs9kBnQ=; b=UQS3B/k+xunirrzV+tvMcg02MyvmEDnR3l2jJhqhhpstE6tUp0q3YumkXuKENfnI7y QZ8VvFnKKZC12jimrPYfgkF3bD+jzixObmDw/iXIxBZr0QdywYapHgy3JNAHgA5y4GYD CRw9P/C68N4AEPDfUDbineMIUKwz6P3l0Bu6ahYl8AA15U3Oljaf7o3wH9uODMpf+Eme vengW7kOX8PxWPtNwzFYOMEjevuV2wgorh/GEEtsgDO1zR2GUC6pegWnSGafoIVSdNEp mHmTAZx0Ed/cIQevHUX9eqtWb8ouKB0cqYDvP+1q+Si51emzjFQyOhZCPulF83Znd2OZ C4ig== X-Forwarded-Encrypted: i=1; AJvYcCXi1mNibiSEfXZKnV7xsVZzkbhqEJdadY3ht7AhOWAddZnTpmy7EFFlp2DJXczpRBil+Sejfo5xuQ==@kvack.org X-Gm-Message-State: AOJu0YzK4jcwpZsdGQfohgU5MLvUfZ9muQqf+M34AWPklNp/j6BO0WQb nScGPKUyu3b+uSCfdrHdT3y/aINkBcrw+Twh0xOlCCuFnr67RmcaC9CSyG1BAs5uBs9Nf8gynWH CzkE0p0N1OPAcx6WcTCFaIS/nz6s= X-Google-Smtp-Source: AGHT+IFgBa+rRuJXH89S8k+th0g/DzvyW19043d/dOWE/cReImEge/pzPQpG9Z0RNe1xCE77XrqFrFmM/WdHfVLicBE= X-Received: by 2002:a05:6102:442a:b0:49b:cfbc:63ac with SMTP id ada2fe7eead31-49fc7532c9emr8946718137.6.1727131128647; Mon, 23 Sep 2024 15:38:48 -0700 (PDT) MIME-Version: 1.0 References: <20240914063746.46290-1-21cnbao@gmail.com> <92f97c8e-f23d-4c6e-9f49-230fb4e96c46@redhat.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 24 Sep 2024 10:38:37 +1200 Message-ID: Subject: Re: [PATCH RFC] mm: mglru: provide a separate list for lazyfree anon folios To: Minchan Kim Cc: David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org, mhocko@suse.com, fengbaopeng@honor.com, gaoxu2@honor.com, hailong.liu@oppo.com, kaleshsingh@google.com, linux-kernel@vger.kernel.org, lokeshgidra@google.com, ngeoffray@google.com, shli@fb.com, surenb@google.com, yipengxiang@honor.com, yuzhao@google.com, Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B268A1C0014 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: zt4uwpdgptun7qkns6sjhu8sb79tpehu X-HE-Tag: 1727131129-433465 X-HE-Meta: U2FsdGVkX1+hDSa7+VoIdHPEJ+qdFKRJdpdWnDTggMbWI1vK5H4eLZ/bjqGCmV+59oipAPtojwSeUAjwxaYm7XIiimnGRPzbIAhOZcJoOXswiAIgqUrmptkHQUiQj+6YMEqUYaqOE50+knS4My9PLBdbN1/ju+6h4olFxZLvKnw90arzoocgf2+jsGlo9oAvBuYfTwt3uc4AU/Sug0Rp0v7wc7kSG6aRwXKPEGL/8NwwojAi8cX2we4WaoTnted86tKQdAQKMihYdf33bnMEimo4xNXfb+mnzeZKaE4PBAaq3WohuJ423wTU2f49I/pCscN0ZdKU+c3CKAMPnM4iE554CCN44xy4tc3oBF7zeV7cdGtN00w/FxCrlj/yptvsrZsCektspHoTdjXOOrtPVpNOg0vmafV501N1P+jNL3SiW5kJ2168L4h1R9qW4UKFRgB3JZzB/XA7i+L95SjfXGRRFb11JbY97yDSb2FRq8cPZxNiwQbLV1PTVf5jYe4ikZgO0fL3OgbhvkKubcZhzjLEPnZK2Xn/z6DsKyMM14ucyL3QyuE/Tdjxw11GWmH6uilbQO4AviEnRzfJJXgsoEffloZYMrW92YkuAauaqKS3Gvh2LQkcuWRVIfIQKeBdJqp5EiRfZp/ET8lVkLfObDZDAykiiJN+y2jaaQ2x67tUpxy/jg4K5lA/wNOkFQMV1WMwbz3IrZcHS/ipGyuzN0YgDdYqxhs5UgtY52DV1r+a7Jhv3fOXEHpLqQa1LzT1Anhsl7oYke98QEQda9nKwJZ2raMI9N90nE8lVMkhGybSWwTKEI4F8UssKd4nJd/AxfLXDbw5rdW9H8iSvFvGru0LvJkABGbxjxOw7Rkv64BZPYCK6miegrxSVllDdnRy4rhTXQik6zqKycQdfX4wl/h4kRao6/u4R1dZ5VqGIW3D6djIt7YAFj3UtxPDpOwCIUBm7ZJGG3akcwlh9B5 7qryfY/W 3eDn2hC5qqgntAnRs9aolM5OVK+CDDUsyv3opox/e6yKP2kLuIABNB5X0P8P8lO7+15rWQxyNR1vAvZMH+7zv+CubbywKPxGktmOotNL+g6sSDxJPMEwS4IzbNhlZVnqLBHVYKKoQrvgZwt96d+6q2YiakdknwUibagfbLcrwwBQqXa0gqYf+yN8pijI1el1E125PJ29vaNma68+TBoPRjy2yJCFWLjLM26IoAJ7u9JanJnXVacoA2RNo/oCwsnBthU4qHJdE+6AtSym3EdW4tkvgLSfELtDOrY14aIIrffXtOn1aUQ/aiaksWbgGUwJbVNTerFrwK5kbsKMZE337/AgbWbpepCefpt6pmUahUy7Jp1rtfgkh3nUbqo9VnX8fh5cLiaOUGE9A1bhmMwT6IBt8mre1i5jLNz4abpEuBI2lXcwADl4t91LM8Z7rKG9bBJj0 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 Tue, Sep 24, 2024 at 10:19=E2=80=AFAM Minchan Kim w= rote: > > On Fri, Sep 20, 2024 at 01:23:57PM +1200, Barry Song wrote: > > On Wed, Sep 18, 2024 at 12:02=E2=80=AFAM David Hildenbrand wrote: > > > > > > On 14.09.24 08:37, Barry Song wrote: > > > > From: Barry Song > > > > > > > > This follows up on the discussion regarding Gaoxu's work[1]. It's > > > > unclear if there's still interest in implementing a separate LRU > > > > list for lazyfree folios, but I decided to explore it out of > > > > curiosity. > > > > > > > > According to Lokesh, MADV_FREE'd anon folios are expected to be > > > > released earlier than file folios. One option, as implemented > > > > by Gao Xu, is to place lazyfree anon folios at the tail of the > > > > file's `min_seq` generation. However, this approach results in > > > > lazyfree folios being released in a LIFO manner, which conflicts > > > > with LRU behavior, as noted by Michal. > > > > > > > > To address this, this patch proposes maintaining a separate list > > > > for lazyfree anon folios while keeping them classified under the > > > > "file" LRU type to minimize code changes. These lazyfree anon > > > > folios will still be counted as file folios and share the same > > > > generation with regular files. In the eviction path, the lazyfree > > > > list will be prioritized for scanning before the actual file > > > > LRU list. > > > > > > > > > > What's the downside of another LRU list? Do we have any experience on= that? > > > > Essentially, the goal is to address the downsides of using a single LRU= list for > > files and lazyfree anonymous pages - seriously more files re-faults. > > > > I'm not entirely clear on the downsides of having an additional LRU > > list. While it > > does increase complexity, it doesn't seem to be significant. > > It's not a catastrophic[1]. I prefer the idea of an additional LRU > because it offers flexibility for various potential use cases[2]. > > orthgonal topic(but may be interest for someone) > > My main interest in a new LRU list is to enable the system to maintain a > quickly reclaimable memory pool and expose the size to the admin with > a knob to decide how many memory pool they want. > > This pool would consist of clean, unmapped pages from both the page cache > and/or the swap cache. This would allow the system to reclaim memory quic= kly > when free memory is low, at the cost of minor fault overhead. My current implementation only handles the MADV_FREE anonymous case. If the= y are placed in a single LRU, they should be able to be reclaimed very quickly, simply discarded without needing to be swapped out. I've been thinking about the issue of unmapped pagecache recently. These unmapped pagecaches can be reclaimed much faster than mapped ones, especially when the latter have a high mapcount and incur significant rmap costs. However, many pagecaches are inherently unmapped (e.g., from syscall read). If they are placed in a single LRU, the challenge would be comparing the age of unmapped pagecache with mapped ones= . Currently, with the mglru tier mechanism, frequently accessed unmapped pagecaches have a chance to be placed in a spot where they are harder to reclaim. personally I am quite interested in putting unmapped pagecache together as right now reclamation could be like this: lru list: unmapped pagecache(A) - mapped pagecached(B) - unmapped pagecache(C) - mapp= ed pagecached with huge mapcount(D) A and C can be reclaimed with zero cost but they have to wait for D and B. But the question is that if make two lists: list1: A - C list2: B - D How can we ensure that A and C won't experience many refaults, even though reclaiming them would be cost-free? Or that B and D might actually be colder than A and C? If this isn't an issue, I'd be very interested in implementing it. Any thou= ghts? > > [1] https://lore.kernel.org/linux-kernel//1448006568-16031-15-git-send-em= ail-minchan@kernel.org/ > [2] https://lkml.org/lkml/2012/6/19/24 Thanks Barry