From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Yu Zhao <yuzhao@google.com>, Andrew Morton <akpm@linux-foundation.org>
Cc: "Andi Kleen" <ak@linux.intel.com>,
"Aneesh Kumar" <aneesh.kumar@linux.ibm.com>,
"Catalin Marinas" <catalin.marinas@arm.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>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Mel Gorman" <mgorman@suse.de>,
"Michael Larabel" <Michael@michaellarabel.com>,
"Michal Hocko" <mhocko@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Tejun Heo" <tj@kernel.org>, "Vlastimil Babka" <vbabka@suse.cz>,
"Will Deacon" <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
page-reclaim@google.com, "Brian Geffon" <bgeffon@google.com>,
"Jan Alexander Steffens" <heftig@archlinux.org>,
"Oleksandr Natalenko" <oleksandr@natalenko.name>,
"Steven Barrett" <steven@liquorix.net>,
"Suleiman Souhlal" <suleiman@google.com>,
"Daniel Byrne" <djbyrne@mtu.edu>,
"Donald Carr" <d@chaos-reins.com>,
"Holger Hoffstätte" <holger@applied-asynchrony.com>,
"Konstantin Kharlamov" <Hi-Angel@yandex.ru>,
"Shuang Zhai" <szhai2@cs.rochester.edu>,
"Sofia Trinh" <sofia.trinh@edi.works>,
"Vaibhav Jain" <vaibhav@linux.ibm.com>
Subject: Re: [PATCH v13 13/14] mm: multi-gen LRU: admin guide
Date: Sun, 10 Jul 2022 09:20:04 +0700 [thread overview]
Message-ID: <f88e270d-4552-0e30-53ef-e6803fbe3afb@gmail.com> (raw)
In-Reply-To: <20220706220022.968789-14-yuzhao@google.com>
On 7/7/22 05:00, Yu Zhao wrote:
> Add an admin guide.
>
> Signed-off-by: Yu Zhao <yuzhao@google.com>
> Acked-by: Brian Geffon <bgeffon@google.com>
> Acked-by: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
> Acked-by: Oleksandr Natalenko <oleksandr@natalenko.name>
> Acked-by: Steven Barrett <steven@liquorix.net>
> Acked-by: Suleiman Souhlal <suleiman@google.com>
> Tested-by: Daniel Byrne <djbyrne@mtu.edu>
> Tested-by: Donald Carr <d@chaos-reins.com>
> Tested-by: Holger Hoffstätte <holger@applied-asynchrony.com>
> Tested-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Tested-by: Shuang Zhai <szhai2@cs.rochester.edu>
> Tested-by: Sofia Trinh <sofia.trinh@edi.works>
> Tested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> Documentation/admin-guide/mm/index.rst | 1 +
> Documentation/admin-guide/mm/multigen_lru.rst | 156 ++++++++++++++++++
> mm/Kconfig | 3 +-
> mm/vmscan.c | 4 +
> 4 files changed, 163 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/admin-guide/mm/multigen_lru.rst
>
> diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst
> index c21b5823f126..2cf5bae62036 100644
> --- a/Documentation/admin-guide/mm/index.rst
> +++ b/Documentation/admin-guide/mm/index.rst
> @@ -32,6 +32,7 @@ the Linux memory management.
> idle_page_tracking
> ksm
> memory-hotplug
> + multigen_lru
> nommu-mmap
> numa_memory_policy
> numaperf
> diff --git a/Documentation/admin-guide/mm/multigen_lru.rst b/Documentation/admin-guide/mm/multigen_lru.rst
> new file mode 100644
> index 000000000000..6355f2b5019d
> --- /dev/null
> +++ b/Documentation/admin-guide/mm/multigen_lru.rst
> @@ -0,0 +1,156 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============
> +Multi-Gen LRU
> +=============
> +The multi-gen LRU is an alternative LRU implementation that optimizes
> +page reclaim and improves performance under memory pressure. Page
> +reclaim decides the kernel's caching policy and ability to overcommit
> +memory. It directly impacts the kswapd CPU usage and RAM efficiency.
> +
> +Quick start
> +===========
> +Build the kernel with the following configurations.
> +
> +* ``CONFIG_LRU_GEN=y``
> +* ``CONFIG_LRU_GEN_ENABLED=y``
> +
> +All set!
> +
> +Runtime options
> +===============
> +``/sys/kernel/mm/lru_gen/`` contains stable ABIs described in the
> +following subsections.
> +
> +Kill switch
> +-----------
> +``enabled`` accepts different values to enable or disable the
> +following components. Its default value depends on
> +``CONFIG_LRU_GEN_ENABLED``. All the components should be enabled
> +unless some of them have unforeseen side effects. Writing to
> +``enabled`` has no effect when a component is not supported by the
> +hardware, and valid values will be accepted even when the main switch
> +is off.
> +
> +====== ===============================================================
> +Values Components
> +====== ===============================================================
> +0x0001 The main switch for the multi-gen LRU.
> +0x0002 Clearing the accessed bit in leaf page table entries in large
> + batches, when MMU sets it (e.g., on x86). This behavior can
> + theoretically worsen lock contention (mmap_lock). If it is
> + disabled, the multi-gen LRU will suffer a minor performance
> + degradation for workloads that contiguously map hot pages,
> + whose accessed bits can be otherwise cleared by fewer larger
> + batches.
> +0x0004 Clearing the accessed bit in non-leaf page table entries as
> + well, when MMU sets it (e.g., on x86). This behavior was not
> + verified on x86 varieties other than Intel and AMD. If it is
> + disabled, the multi-gen LRU will suffer a negligible
> + performance degradation.
> +[yYnN] Apply to all the components above.
> +====== ===============================================================
> +
> +E.g.,
> +::
In this case, it would be better to say "For example".
> +
> + echo y >/sys/kernel/mm/lru_gen/enabled
> + cat /sys/kernel/mm/lru_gen/enabled
> + 0x0007
> + echo 5 >/sys/kernel/mm/lru_gen/enabled
> + cat /sys/kernel/mm/lru_gen/enabled
> + 0x0005
> +
> +Thrashing prevention
> +--------------------
> +Personal computers are more sensitive to thrashing because it can
> +cause janks (lags when rendering UI) and negatively impact user
> +experience. The multi-gen LRU offers thrashing prevention to the
> +majority of laptop and desktop users who do not have ``oomd``.
> +
> +Users can write ``N`` to ``min_ttl_ms`` to prevent the working set of
> +``N`` milliseconds from getting evicted. The OOM killer is triggered
> +if this working set cannot be kept in memory. In other words, this
> +option works as an adjustable pressure relief valve, and when open, it
> +terminates applications that are hopefully not being used.
> +
> +Based on the average human detectable lag (~100ms), ``N=1000`` usually
> +eliminates intolerable janks due to thrashing. Larger values like
> +``N=3000`` make janks less noticeable at the risk of premature OOM
> +kills.
> +
> +The default value ``0`` means disabled.
> +
> +Experimental features
> +=====================
> +``/sys/kernel/debug/lru_gen`` accepts commands described in the
> +following subsections. Multiple command lines are supported, so does
> +concatenation with delimiters ``,`` and ``;``.
> +
> +``/sys/kernel/debug/lru_gen_full`` provides additional stats for
> +debugging. ``CONFIG_LRU_GEN_STATS=y`` keeps historical stats from
> +evicted generations in this file.
> +
> +Working set estimation
> +----------------------
> +Working set estimation measures how much memory an application needs
> +in a given time interval, and it is usually done with little impact on
> +the performance of the application. E.g., data centers want to
> +optimize job scheduling (bin packing) to improve memory utilizations.
> +When a new job comes in, the job scheduler needs to find out whether
> +each server it manages can allocate a certain amount of memory for
> +this new job before it can pick a candidate. To do so, the job
> +scheduler needs to estimate the working sets of the existing jobs.
> +
> +When it is read, ``lru_gen`` returns a histogram of numbers of pages
> +accessed over different time intervals for each memcg and node.
> +``MAX_NR_GENS`` decides the number of bins for each histogram. The
> +histograms are noncumulative.
> +::
> +
> + memcg memcg_id memcg_path
> + node node_id
> + min_gen_nr age_in_ms nr_anon_pages nr_file_pages
> + ...
> + max_gen_nr age_in_ms nr_anon_pages nr_file_pages
> +
> +Each bin contains an estimated number of pages that have been accessed
> +within ``age_in_ms``. E.g., ``min_gen_nr`` contains the coldest pages
> +and ``max_gen_nr`` contains the hottest pages, since ``age_in_ms`` of
> +the former is the largest and that of the latter is the smallest.
> +
> +Users can write ``+ memcg_id node_id max_gen_nr
> +[can_swap [force_scan]]`` to ``lru_gen`` to create a new generation
> +``max_gen_nr+1``. ``can_swap`` defaults to the swap setting and, if it
> +is set to ``1``, it forces the scan of anon pages when swap is off,
> +and vice versa. ``force_scan`` defaults to ``1`` and, if it is set to
> +``0``, it employs heuristics to reduce the overhead, which is likely
> +to reduce the coverage as well.
> +
> +A typical use case is that a job scheduler writes to ``lru_gen`` at a
> +certain time interval to create new generations, and it ranks the
> +servers it manages based on the sizes of their cold pages defined by
> +this time interval.
> +
> +Proactive reclaim
> +-----------------
> +Proactive reclaim induces page reclaim when there is no memory
> +pressure. It usually targets cold pages only. E.g., when a new job
> +comes in, the job scheduler wants to proactively reclaim cold pages on
> +the server it selected to improve the chance of successfully landing
> +this new job.
> +
> +Users can write ``- memcg_id node_id min_gen_nr [swappiness
> +[nr_to_reclaim]]`` to ``lru_gen`` to evict generations less than or
> +equal to ``min_gen_nr``. Note that ``min_gen_nr`` should be less than
> +``max_gen_nr-1`` as ``max_gen_nr`` and ``max_gen_nr-1`` are not fully
> +aged and therefore cannot be evicted. ``swappiness`` overrides the
> +default value in ``/proc/sys/vm/swappiness``. ``nr_to_reclaim`` limits
> +the number of pages to evict.
> +
> +A typical use case is that a job scheduler writes to ``lru_gen``
> +before it tries to land a new job on a server. If it fails to
> +materialize enough cold pages because of the overestimation, it
> +retries on the next server according to the ranking result obtained
> +from the working set estimation step. This less forceful approach
> +limits the impacts on the existing jobs.
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 0c2ef0af0036..a0f7b6e66410 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1137,7 +1137,8 @@ config LRU_GEN
> # make sure folio->flags has enough spare bits
> depends on 64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP
> help
> - A high performance LRU implementation to overcommit memory.
> + A high performance LRU implementation to overcommit memory. See
> + Documentation/admin-guide/mm/multigen_lru.rst for details.
>
> config LRU_GEN_ENABLED
> bool "Enable by default"
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fbcd298adca7..7096ff7836db 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -5209,6 +5209,7 @@ static ssize_t show_min_ttl(struct kobject *kobj, struct kobj_attribute *attr, c
> return sprintf(buf, "%u\n", jiffies_to_msecs(READ_ONCE(lru_gen_min_ttl)));
> }
>
> +/* see Documentation/admin-guide/mm/multigen_lru.rst for details */
> static ssize_t store_min_ttl(struct kobject *kobj, struct kobj_attribute *attr,
> const char *buf, size_t len)
> {
> @@ -5242,6 +5243,7 @@ static ssize_t show_enabled(struct kobject *kobj, struct kobj_attribute *attr, c
> return snprintf(buf, PAGE_SIZE, "0x%04x\n", caps);
> }
>
> +/* see Documentation/admin-guide/mm/multigen_lru.rst for details */
> static ssize_t store_enabled(struct kobject *kobj, struct kobj_attribute *attr,
> const char *buf, size_t len)
> {
> @@ -5389,6 +5391,7 @@ static void lru_gen_seq_show_full(struct seq_file *m, struct lruvec *lruvec,
> seq_putc(m, '\n');
> }
>
> +/* see Documentation/admin-guide/mm/multigen_lru.rst for details */
> static int lru_gen_seq_show(struct seq_file *m, void *v)
> {
> unsigned long seq;
> @@ -5547,6 +5550,7 @@ static int run_cmd(char cmd, int memcg_id, int nid, unsigned long seq,
> return err;
> }
>
> +/* see Documentation/admin-guide/mm/multigen_lru.rst for details */
> static ssize_t lru_gen_seq_write(struct file *file, const char __user *src,
> size_t len, loff_t *pos)
> {
Otherwise looks good (no new warnings).
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
next prev parent reply other threads:[~2022-07-10 2:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-06 22:00 [PATCH v13 00/14] Multi-Gen LRU Framework Yu Zhao
2022-07-06 22:00 ` [PATCH v13 01/14] mm: x86, arm64: add arch_has_hw_pte_young() Yu Zhao
2022-07-06 22:00 ` [PATCH v13 02/14] mm: x86: add CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG Yu Zhao
2022-07-06 22:00 ` [PATCH v13 03/14] mm/vmscan.c: refactor shrink_node() Yu Zhao
2022-07-06 22:00 ` [PATCH v13 04/14] Revert "include/linux/mm_inline.h: fold __update_lru_size() into its sole caller" Yu Zhao
2022-07-06 22:00 ` [PATCH v13 05/14] mm: multi-gen LRU: groundwork Yu Zhao
2022-07-06 22:00 ` [PATCH v13 06/14] mm: multi-gen LRU: minimal implementation Yu Zhao
2022-07-06 22:00 ` [PATCH v13 07/14] mm: multi-gen LRU: exploit locality in rmap Yu Zhao
2022-07-06 22:00 ` [PATCH v13 08/14] mm: multi-gen LRU: support page table walks Yu Zhao
2022-07-06 22:26 ` Yu Zhao
2022-07-07 1:23 ` Liam Howlett
2022-07-06 22:00 ` [PATCH v13 09/14] mm: multi-gen LRU: optimize multiple memcgs Yu Zhao
2022-07-06 22:00 ` [PATCH v13 10/14] mm: multi-gen LRU: kill switch Yu Zhao
2022-07-06 22:00 ` [PATCH v13 11/14] mm: multi-gen LRU: thrashing prevention Yu Zhao
2022-07-06 22:00 ` [PATCH v13 12/14] mm: multi-gen LRU: debugfs interface Yu Zhao
2022-07-06 22:00 ` [PATCH v13 13/14] mm: multi-gen LRU: admin guide Yu Zhao
2022-07-10 2:20 ` Bagas Sanjaya [this message]
2022-07-06 22:00 ` [PATCH v13 14/14] mm: multi-gen LRU: design doc Yu Zhao
2022-07-10 2:21 ` Bagas Sanjaya
2022-07-07 3:03 ` [PATCH v13 00/14] Multi-Gen LRU Framework Bagas Sanjaya
2022-07-09 19:31 ` Yu Zhao
2022-07-10 1:09 ` Bagas Sanjaya
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=f88e270d-4552-0e30-53ef-e6803fbe3afb@gmail.com \
--to=bagasdotme@gmail.com \
--cc=Hi-Angel@yandex.ru \
--cc=Michael@michaellarabel.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=bgeffon@google.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=d@chaos-reins.com \
--cc=dave.hansen@linux.intel.com \
--cc=djbyrne@mtu.edu \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=heftig@archlinux.org \
--cc=holger@applied-asynchrony.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=oleksandr@natalenko.name \
--cc=page-reclaim@google.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=sofia.trinh@edi.works \
--cc=steven@liquorix.net \
--cc=suleiman@google.com \
--cc=szhai2@cs.rochester.edu \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vaibhav@linux.ibm.com \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@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