From: SeongJae Park <sj38.park@gmail.com>
To: Yu Zhao <yuzhao@google.com>
Cc: linux-mm@kvack.org, Andi Kleen <ak@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Benjamin Manes <ben.manes@gmail.com>,
Dave Chinner <david@fromorbit.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Hillf Danton <hdanton@sina.com>, Jens Axboe <axboe@kernel.dk>,
Johannes Weiner <hannes@cmpxchg.org>,
Jonathan Corbet <corbet@lwn.net>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Matthew Wilcox <willy@infradead.org>,
Mel Gorman <mgorman@suse.de>, Miaohe Lin <linmiaohe@huawei.com>,
Michael Larabel <michael@michaellarabel.com>,
Michal Hocko <mhocko@suse.com>,
Michel Lespinasse <michel@lespinasse.org>,
Rik van Riel <riel@surriel.com>, Roman Gushchin <guro@fb.com>,
Rong Chen <rong.a.chen@intel.com>,
SeongJae Park <sjpark@amazon.de>,
Tim Chen <tim.c.chen@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>, Yang Shi <shy828301@gmail.com>,
Ying Huang <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>,
linux-kernel@vger.kernel.org, lkp@lists.01.org,
page-reclaim@google.com
Subject: Re: [PATCH v2 00/16] Multigenerational LRU Framework
Date: Tue, 13 Apr 2021 07:51:55 +0000 [thread overview]
Message-ID: <20210413075155.32652-1-sjpark@amazon.de> (raw)
In-Reply-To: <20210413065633.2782273-1-yuzhao@google.com>
From: SeongJae Park <sjpark@amazon.de>
Hello,
Very interesting work, thank you for sharing this :)
On Tue, 13 Apr 2021 00:56:17 -0600 Yu Zhao <yuzhao@google.com> wrote:
> What's new in v2
> ================
> Special thanks to Jens Axboe for reporting a regression in buffered
> I/O and helping test the fix.
Is the discussion open? If so, could you please give me a link?
>
> This version includes the support of tiers, which represent levels of
> usage from file descriptors only. Pages accessed N times via file
> descriptors belong to tier order_base_2(N). Each generation contains
> at most MAX_NR_TIERS tiers, and they require additional MAX_NR_TIERS-2
> bits in page->flags. In contrast to moving across generations which
> requires the lru lock, moving across tiers only involves an atomic
> operation on page->flags and therefore has a negligible cost. A
> feedback loop modeled after the well-known PID controller monitors the
> refault rates across all tiers and decides when to activate pages from
> which tiers, on the reclaim path.
>
> This feedback model has a few advantages over the current feedforward
> model:
> 1) It has a negligible overhead in the buffered I/O access path
> because activations are done in the reclaim path.
> 2) It takes mapped pages into account and avoids overprotecting pages
> accessed multiple times via file descriptors.
> 3) More tiers offer better protection to pages accessed more than
> twice when buffered-I/O-intensive workloads are under memory
> pressure.
>
> The fio/io_uring benchmark shows 14% improvement in IOPS when randomly
> accessing Samsung PM981a in the buffered I/O mode.
Improvement under memory pressure, right? How much pressure?
[...]
>
> Differential scans via page tables
> ----------------------------------
> Each differential scan discovers all pages that have been referenced
> since the last scan. Specifically, it walks the mm_struct list
> associated with an lruvec to scan page tables of processes that have
> been scheduled since the last scan.
Does this means it scans only virtual address spaces of processes and therefore
pages in the page cache that are not mmap()-ed will not be scanned?
> The cost of each differential scan
> is roughly proportional to the number of referenced pages it
> discovers. Unless address spaces are extremely sparse, page tables
> usually have better memory locality than the rmap. The end result is
> generally a significant reduction in CPU usage, for workloads using a
> large amount of anon memory.
When and how frequently it scans?
Thanks,
SeongJae Park
[...]
next prev parent reply other threads:[~2021-04-13 7:52 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 6:56 [PATCH v2 00/16] Multigenerational LRU Framework Yu Zhao
2021-04-13 6:56 ` [PATCH v2 01/16] include/linux/memcontrol.h: do not warn in page_memcg_rcu() if !CONFIG_MEMCG Yu Zhao
2021-04-13 6:56 ` [PATCH v2 02/16] include/linux/nodemask.h: define next_memory_node() if !CONFIG_NUMA Yu Zhao
2021-04-13 6:56 ` [PATCH v2 03/16] include/linux/huge_mm.h: define is_huge_zero_pmd() if !CONFIG_TRANSPARENT_HUGEPAGE Yu Zhao
2021-04-13 6:56 ` [PATCH v2 04/16] include/linux/cgroup.h: export cgroup_mutex Yu Zhao
2021-04-13 6:56 ` [PATCH v2 05/16] mm/swap.c: export activate_page() Yu Zhao
2021-04-13 6:56 ` [PATCH v2 06/16] mm, x86: support the access bit on non-leaf PMD entries Yu Zhao
2021-04-13 6:56 ` [PATCH v2 07/16] mm/vmscan.c: refactor shrink_node() Yu Zhao
2021-04-13 6:56 ` [PATCH v2 08/16] mm: multigenerational lru: groundwork Yu Zhao
2021-04-13 6:56 ` [PATCH v2 09/16] mm: multigenerational lru: activation Yu Zhao
2021-04-13 6:56 ` [PATCH v2 10/16] mm: multigenerational lru: mm_struct list Yu Zhao
2021-04-14 14:36 ` Matthew Wilcox
2021-04-13 6:56 ` [PATCH v2 11/16] mm: multigenerational lru: aging Yu Zhao
2021-04-13 6:56 ` [PATCH v2 12/16] mm: multigenerational lru: eviction Yu Zhao
2021-04-13 6:56 ` [PATCH v2 13/16] mm: multigenerational lru: page reclaim Yu Zhao
2021-04-13 6:56 ` [PATCH v2 14/16] mm: multigenerational lru: user interface Yu Zhao
2021-04-13 6:56 ` [PATCH v2 15/16] mm: multigenerational lru: Kconfig Yu Zhao
2021-04-13 6:56 ` [PATCH v2 16/16] mm: multigenerational lru: documentation Yu Zhao
2021-04-13 7:51 ` SeongJae Park [this message]
2021-04-13 16:13 ` [PATCH v2 00/16] Multigenerational LRU Framework Jens Axboe
2021-04-13 16:42 ` SeongJae Park
2021-04-13 23:14 ` Dave Chinner
2021-04-14 2:29 ` Rik van Riel
[not found] ` <CAOUHufafMcaG8sOS=1YMy2P_6p0R1FzP16bCwpUau7g1-PybBQ@mail.gmail.com>
2021-04-14 6:15 ` Huang, Ying
2021-04-14 7:58 ` Yu Zhao
2021-04-14 8:27 ` Huang, Ying
2021-04-14 13:51 ` Rik van Riel
2021-04-14 15:56 ` Andi Kleen
2021-04-14 15:58 ` [page-reclaim] " Shakeel Butt
2021-04-14 18:45 ` Yu Zhao
2021-04-14 15:51 ` Andi Kleen
2021-04-14 15:58 ` Rik van Riel
2021-04-14 19:14 ` Yu Zhao
2021-04-14 19:41 ` Rik van Riel
2021-04-14 20:08 ` Yu Zhao
2021-04-14 19:04 ` Yu Zhao
2021-04-15 3:00 ` Andi Kleen
2021-04-15 7:13 ` Yu Zhao
2021-04-15 8:19 ` Huang, Ying
2021-04-15 9:57 ` Michel Lespinasse
2021-04-24 2:33 ` Yu Zhao
2021-04-24 3:30 ` Andi Kleen
2021-04-24 4:16 ` Yu Zhao
2021-04-14 3:40 ` Yu Zhao
2021-04-14 4:50 ` Dave Chinner
2021-04-14 7:16 ` Yu Zhao
2021-04-14 10:00 ` Yu Zhao
2021-04-15 1:36 ` Dave Chinner
2021-04-24 21:21 ` Yu Zhao
2021-04-14 14:43 ` Jens Axboe
2021-04-14 19:42 ` Yu Zhao
2021-04-15 1:21 ` Dave Chinner
2021-04-14 17:43 ` Johannes Weiner
2021-04-27 10:35 ` Yu Zhao
2021-04-29 23:46 ` Konstantin Kharlamov
2021-04-30 6:37 ` Konstantin Kharlamov
2021-04-30 19: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=20210413075155.32652-1-sjpark@amazon.de \
--to=sj38.park@gmail.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=ben.manes@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@fromorbit.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@lists.01.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=michael@michaellarabel.com \
--cc=michel@lespinasse.org \
--cc=page-reclaim@google.com \
--cc=riel@surriel.com \
--cc=rong.a.chen@intel.com \
--cc=shy828301@gmail.com \
--cc=sjpark@amazon.de \
--cc=tim.c.chen@linux.intel.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.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;
as well as URLs for NNTP newsgroup(s).