Date:   Mon, 15 Mar 2021 20:24:56 -0600
From:   Yu Zhao <yuzhao@...gle.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     linux-mm@...ck.org, Alex Shi <alex.shi@...ux.alibaba.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Hillf Danton <hdanton@...a.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Matthew Wilcox <willy@...radead.org>,
        Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...e.com>,
        Roman Gushchin <guro@...com>, Vlastimil Babka <vbabka@...e.cz>,
        Wei Yang <richard.weiyang@...ux.alibaba.com>,
        Yang Shi <shy828301@...il.com>,
        Ying Huang <ying.huang@...el.com>,
        linux-kernel@...r.kernel.org, page-reclaim@...gle.com
Subject: Re: [PATCH v1 00/14] Multigenerational LRU

On Mon, Mar 15, 2021 at 11:00:06AM -0700, Dave Hansen wrote:
> On 3/12/21 11:57 PM, Yu Zhao wrote:
> > Background
> > ==========
> > DRAM is a major factor in total cost of ownership, and improving
> > memory overcommit brings a high return on investment. Over the past
> > decade of research and experimentation in memory overcommit, we
> > observed a distinct trend across millions of servers and clients: the
> > size of page cache has been decreasing because of the growing
> > popularity of cloud storage. Nowadays anon pages account for more than
> > 90% of our memory consumption and page cache contains mostly
> > executable pages.
> 
> This makes a compelling argument that current reclaim is not well
> optimized for anonymous memory with low rates of sharing.  Basically,
> anonymous rmap is very powerful, but we're not getting enough bang for
> our buck out of it.
> 
> I also understand that the workloads you reference are anonymous-heavy
> and that page cache isn't a *major* component.
> 
> But, what does happens to page-cache-heavy workloads?  Does this just
> effectively force databases that want to use shmem over to hugetlbfs?

No, they should benefit too. In terms of page reclaim, shmem pages are
basically considered anon: they are on anon lru and dirty shmem pages
can only be swapped (we can safely assume clean shmem pages are
virtually nonexistent) in contrast to file pages that have backing
storage and need to be written back.

I should have phrased it better: our accounting is based on what the
kernel provides, i.e., anon/file (lru) sizes you listed below.

> How bad does this scanning get in the worst case if there's a lot of
> sharing?

Actually the improvement is larger when there is more sharing, i.e.,
higher map_count larger improvement. Let's assume we have a shmem
page mapped by two processes. To reclaim this page, we need to make
sure neither PTE from the two sets of page tables has the accessed
bit. The current page reclaim uses the rmap, i.e., rmap_walk_file().
It first looks up the two VMAs (from the two processes mapping this
shmem file) in the interval tree of this shmem file, then from each
VMA, it goes through PGD/PUD/PMD to reach the PTE. The page can't be
reclaimed if either of the PTEs has the accessed bit, therefore cost
of the scanning is more than proportional to the number of accesses,
when there is a lot sharing.

Why this series makes it better? We track the usage of page tables.
Specifically, we work alongside switch_mm(): if one of the processes
above hasn't be scheduled since the last scan, we don't need to scan
its page tables. So the cost is roughly proportional to the number of
accesses, regardless of how many processes. And instead of scanning
pages one by one, we do it in large batches. However, page tables can
be very sparse -- this is not a problem for the rmap because it knows
exactly where the PTEs are (by vma_address()). We only know ranges (by
vma->vm_start/vm_end). This is where the accessed bit on non-leaf
PMDs can be of help.

But I guess you are wondering what downsides are. Well, we haven't
seen any (yet). We do have page cache (non-shmem) heavy workloads,
but not at a scale large enough to make any statistically meaningful
observations. We are very interested in working with anybody who has
page cache (non-shmem) heavy workloads and is willing to try out this
series.

> I'm kinda surprised by this, but my 16GB laptop has a lot more page
> cache than I would have guessed:
> 
> > Active(anon):    4065088 kB
> > Inactive(anon):  3981928 kB
> > Active(file):    2260580 kB
> > Inactive(file):  3738096 kB
> > AnonPages:       6624776 kB
> > Mapped:           692036 kB
> > Shmem:            776276 kB
> 
> Most of it isn't mapped, but it's far from all being used for text.

We have categorized two groups:
  1) average users that haven't experienced memory pressure since
  their systems have booted. The booting process fills up page cache
  with one-off file pages, and they remain until users experience
  memory pressure. This can be confirmed by looking at those counters
  of a freshly rebooted and idle system. My guess this is the case for
  your laptop.
  2) engineering users who store git repos and compile locally. They
  complained about their browsers being janky because anon memory got
  swapped even though their systems had a lot of stale file pages in
  page cache, with the current page reclaim. They are what we consider
  part of the page cache (non-shmem) heavy group.

Powered by blists - more mailing lists