linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kairui Song <ryncsn@gmail.com>
To: Yu Zhao <yuzhao@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	Charan Teja Kalla <quic_charante@quicinc.com>,
	 Kalesh Singh <kaleshsingh@google.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH mm-unstable v1 1/4] mm/mglru: fix underprotected page cache
Date: Tue, 12 Dec 2023 14:52:08 +0800	[thread overview]
Message-ID: <CAMgjq7AtceR-CXnKFfQHM3qi0y4oGyJ4_sw_uh5EkpXCBzkCXg@mail.gmail.com> (raw)
In-Reply-To: <CAOUHufYwZAUaJh6i8Fazc4gVMSqcsz9JbRNpj0cpx2qR+bZBFw@mail.gmail.com>

Yu Zhao <yuzhao@google.com> 于2023年12月12日周二 06:07写道:
>
> On Fri, Dec 8, 2023 at 1:24 AM Kairui Song <ryncsn@gmail.com> wrote:
> >
> > Yu Zhao <yuzhao@google.com> 于2023年12月8日周五 14:14写道:
> > >
> > > Unmapped folios accessed through file descriptors can be
> > > underprotected. Those folios are added to the oldest generation based
> > > on:
> > > 1. The fact that they are less costly to reclaim (no need to walk the
> > >    rmap and flush the TLB) and have less impact on performance (don't
> > >    cause major PFs and can be non-blocking if needed again).
> > > 2. The observation that they are likely to be single-use. E.g., for
> > >    client use cases like Android, its apps parse configuration files
> > >    and store the data in heap (anon); for server use cases like MySQL,
> > >    it reads from InnoDB files and holds the cached data for tables in
> > >    buffer pools (anon).
> > >
> > > However, the oldest generation can be very short lived, and if so, it
> > > doesn't provide the PID controller with enough time to respond to a
> > > surge of refaults. (Note that the PID controller uses weighted
> > > refaults and those from evicted generations only take a half of the
> > > whole weight.) In other words, for a short lived generation, the
> > > moving average smooths out the spike quickly.
> > >
> > > To fix the problem:
> > > 1. For folios that are already on LRU, if they can be beyond the
> > >    tracking range of tiers, i.e., five accesses through file
> > >    descriptors, move them to the second oldest generation to give them
> > >    more time to age. (Note that tiers are used by the PID controller
> > >    to statistically determine whether folios accessed multiple times
> > >    through file descriptors are worth protecting.)
> > > 2. When adding unmapped folios to LRU, adjust the placement of them so
> > >    that they are not too close to the tail. The effect of this is
> > >    similar to the above.
> > >
> > > On Android, launching 55 apps sequentially:
> > >                            Before     After      Change
> > >   workingset_refault_anon  25641024   25598972   0%
> > >   workingset_refault_file  115016834  106178438  -8%
> >
> > Hi Yu,
> >
> > Thanks you for your amazing works on MGLRU.
> >
> > I believe this is the similar issue I was trying to resolve previously:
> > https://lwn.net/Articles/945266/
> > The idea is to use refault distance to decide if the page should be
> > place in oldest generation or some other gen, which per my test,
> > worked very well, and we have been using refault distance for MGLRU in
> > multiple workloads.
> >
> > There are a few issues left in my previous RFC series, like anon pages
> > in MGLRU shouldn't be considered, I wanted to collect feedback or test
> > cases, but unfortunately it seems didn't get too much attention
> > upstream.
> >
> > I think both this patch and my previous series are for solving the
> > file pages underpertected issue, and I did a quick test using this
> > series, for mongodb test, refault distance seems still a better
> > solution (I'm not saying these two optimization are mutually exclusive
> > though, just they do have some conflicts in implementation and solving
> > similar problem):
> >
> > Previous result:
> > ==================================================================
> > Execution Results after 905 seconds
> > ------------------------------------------------------------------
> >                   Executed        Time (µs)       Rate
> >   STOCK_LEVEL     2542            27121571486.2   0.09 txn/s
> > ------------------------------------------------------------------
> >   TOTAL           2542            27121571486.2   0.09 txn/s
> >
> > This patch:
> > ==================================================================
> > Execution Results after 900 seconds
> > ------------------------------------------------------------------
> >                   Executed        Time (µs)       Rate
> >   STOCK_LEVEL     1594            27061522574.4   0.06 txn/s
> > ------------------------------------------------------------------
> >   TOTAL           1594            27061522574.4   0.06 txn/s
> >
> > Unpatched version is always around ~500.
>
> Thanks for the test results!
>
> > I think there are a few points here:
> > - Refault distance make use of page shadow so it can better
> > distinguish evicted pages of different access pattern (re-access
> > distance).
> > - Throttled refault distance can help hold part of workingset when
> > memory is too small to hold the whole workingset.
> >
> > So maybe part of this patch and the bits of previous series can be
> > combined to work better on this issue, how do you think?
>
> I'll try to find some time this week to look at your RFC. It'd be a

Thanks!

> lot easier for me if you could share
> 1. your latest tree, preferably based on the mainline, and
> 2. your VM image containing the above test.

Sure, I'll update the RFC and try to provide an easier test reproducer.


  reply	other threads:[~2023-12-12  6:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08  6:14 Yu Zhao
2023-12-08  6:14 ` [PATCH mm-unstable v1 2/4] mm/mglru: try to stop at high watermarks Yu Zhao
2023-12-08 11:00   ` Hillf Danton
2023-12-11 22:01     ` Yu Zhao
2023-12-08  6:14 ` [PATCH mm-unstable v1 3/4] mm/mglru: respect min_ttl_ms with memcgs Yu Zhao
2023-12-08  6:14 ` [PATCH mm-unstable v1 4/4] mm/mglru: reclaim offlined memcgs harder Yu Zhao
2023-12-08  8:24 ` [PATCH mm-unstable v1 1/4] mm/mglru: fix underprotected page cache Kairui Song
2023-12-11 22:06   ` Yu Zhao
2023-12-12  6:52     ` Kairui Song [this message]
2023-12-13  3:02       ` Kairui Song
2023-12-13  7:59         ` Yu Zhao
2023-12-14  3:09           ` Yu Zhao
2023-12-14 18:37             ` Kairui Song
2023-12-14 23:51               ` Yu Zhao
2023-12-15  4:56                 ` Yu Zhao
2023-12-18 18:05                   ` Kairui Song
2023-12-19  3:21                     ` Yu Zhao
2023-12-19  3:44                       ` Yu Zhao
2023-12-19 18:58                         ` Kairui Song
2023-12-20  6:38                           ` Yu Zhao
2023-12-20  8:16                             ` Yu Zhao
2023-12-20  8:24                               ` Kairui Song
2023-12-25  6:30                                 ` Yu Zhao
2023-12-25 12:02                                   ` Kairui Song
2023-12-25 21:52                                     ` Yu Zhao
2023-12-25 22:00                                       ` Yu Zhao
2024-01-10 19:16                                         ` Kairui Song
2024-01-11  7:02                                           ` Yu Zhao
2023-12-17 18:31                 ` Yu Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMgjq7AtceR-CXnKFfQHM3qi0y4oGyJ4_sw_uh5EkpXCBzkCXg@mail.gmail.com \
    --to=ryncsn@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=kaleshsingh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=quic_charante@quicinc.com \
    --cc=stable@vger.kernel.org \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox