linux.git/Documentation/admin-guide/sysctl/vm.rst, branch v6.7

docs: mm: fix vm overcommit documentation for OVERCOMMIT_GUESS

2023-10-10T19:35:55+00:00

Commit 8c7829b04c52 "mm: fix false-positive OVERCOMMIT_GUESS failures"
changed the behavior of the default OVERCOMMIT_GUESS setting.
Reflect the change also in the Documentation, namely files:
    Documentation/admin-guide/sysctl/vm.rst
    Documentation/mm/overcommit-accounting.rst

Reported-by: Jozef Bacik 
Signed-off-by: Vratislav Bendel 
Acked-by: Mike Rapoport 
Signed-off-by: Jonathan Corbet 
Link: https://lore.kernel.org/r/20220829124638.63748-1-vbendel@redhat.com

Documentation: admin-guide: correct spelling

2023-02-02T18:04:42+00:00

Correct spelling problems for Documentation/admin-guide/ as reported
by codespell.

Signed-off-by: Randy Dunlap 
Reviewed-by: Mukesh Ojha 
Cc: Tejun Heo 
Cc: Zefan Li 
Cc: Johannes Weiner 
Cc: cgroups@vger.kernel.org
Cc: Alasdair Kergon 
Cc: Mike Snitzer 
Cc: dm-devel@redhat.com
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
Cc: linux-mm@kvack.org
Link: https://lore.kernel.org/r/20230129231053.20863-2-rdunlap@infradead.org
Signed-off-by: Jonathan Corbet

userfaultfd: update documentation to describe /dev/userfaultfd

2022-09-12T03:25:49+00:00

Explain the different ways to create a new userfaultfd, and how access
control works for each way.

[axelrasmussen@google.com: improve wording in documentation, per Mike]
  Link: https://lkml.kernel.org/r/20220819205201.658693-5-axelrasmussen@google.com
Link: https://lkml.kernel.org/r/20220808175614.3885028-5-axelrasmussen@google.com
Signed-off-by: Axel Rasmussen 
Acked-by: Peter Xu 
Reviewed-by: Shuah Khan 
Cc: Al Viro 
Cc: Dave Hansen 
Cc: Dmitry V. Levin 
Cc: Gleb Fotengauer-Malinovskiy 
Cc: Hugh Dickins 
Cc: Jan Kara 
Cc: Jonathan Corbet 
Cc: Mel Gorman 
Cc: Mike Kravetz 
Cc: Mike Rapoport 
Cc: Nadav Amit 
Cc: Suren Baghdasaryan 
Cc: Vlastimil Babka 
Cc: Zhang Yi 
Cc: Mike Rapoport 
Signed-off-by: Andrew Morton

mm: hugetlb_vmemmap: introduce the name HVO

2022-08-09T01:06:42+00:00

It it inconvenient to mention the feature of optimizing vmemmap pages
associated with HugeTLB pages when communicating with others since there
is no specific or abbreviated name for it when it is first introduced. 
Let us give it a name HVO (HugeTLB Vmemmap Optimization) from now.

This commit also updates the document about "hugetlb_free_vmemmap" by the
way discussed in thread [1].

Link: https://lore.kernel.org/all/21aae898-d54d-cc4b-a11f-1bb7fddcfffa@redhat.com/ [1]
Link: https://lkml.kernel.org/r/20220628092235.91270-4-songmuchun@bytedance.com
Signed-off-by: Muchun Song 
Reviewed-by: Oscar Salvador 
Reviewed-by: Mike Kravetz 
Cc: Anshuman Khandual 
Cc: Catalin Marinas 
Cc: David Hildenbrand 
Cc: Jonathan Corbet 
Cc: Will Deacon 
Cc: Xiongchun Duan 
Signed-off-by: Andrew Morton

mm: memory_hotplug: make hugetlb_optimize_vmemmap compatible with memmap_on_memory

2022-07-04T01:08:49+00:00

For now, the feature of hugetlb_free_vmemmap is not compatible with the
feature of memory_hotplug.memmap_on_memory, and hugetlb_free_vmemmap takes
precedence over memory_hotplug.memmap_on_memory.  However, someone wants
to make memory_hotplug.memmap_on_memory takes precedence over
hugetlb_free_vmemmap since memmap_on_memory makes it more likely to
succeed memory hotplug in close-to-OOM situations.  So the decision of
making hugetlb_free_vmemmap take precedence is not wise and elegant.

The proper approach is to have hugetlb_vmemmap.c do the check whether the
section which the HugeTLB pages belong to can be optimized.  If the
section's vmemmap pages are allocated from the added memory block itself,
hugetlb_free_vmemmap should refuse to optimize the vmemmap, otherwise, do
the optimization.  Then both kernel parameters are compatible.  So this
patch introduces VmemmapSelfHosted to mask any non-optimizable vmemmap
pages.  The hugetlb_vmemmap can use this flag to detect if a vmemmap page
can be optimized.

[songmuchun@bytedance.com: walk vmemmap page tables to avoid false-positive]
  Link: https://lkml.kernel.org/r/20220620110616.12056-3-songmuchun@bytedance.com
Link: https://lkml.kernel.org/r/20220617135650.74901-3-songmuchun@bytedance.com
Signed-off-by: Muchun Song 
Co-developed-by: Oscar Salvador 
Signed-off-by: Oscar Salvador 
Acked-by: David Hildenbrand 
Cc: Jonathan Corbet 
Cc: Mike Kravetz 
Cc: Paul E. McKenney 
Cc: Xiongchun Duan 
Signed-off-by: Andrew Morton

docs: rename Documentation/vm to Documentation/mm

2022-06-27T19:52:53+00:00

so it will be consistent with code mm directory and with
Documentation/admin-guide/mm and won't be confused with virtual machines.

Signed-off-by: Mike Rapoport 
Suggested-by: Matthew Wilcox 
Tested-by: Ira Weiny 
Acked-by: Jonathan Corbet 
Acked-by: Wu XiangCheng

mm: hugetlb_vmemmap: add hugetlb_optimize_vmemmap sysctl

2022-05-13T23:48:56+00:00

We must add hugetlb_free_vmemmap=on (or "off") to the boot cmdline and
reboot the server to enable or disable the feature of optimizing vmemmap
pages associated with HugeTLB pages.  However, rebooting usually takes a
long time.  So add a sysctl to enable or disable the feature at runtime
without rebooting.  Why we need this?  There are 3 use cases.

1) The feature of minimizing overhead of struct page associated with
   each HugeTLB is disabled by default without passing
   "hugetlb_free_vmemmap=on" to the boot cmdline.  When we (ByteDance)
   deliver the servers to the users who want to enable this feature, they
   have to configure the grub (change boot cmdline) and reboot the
   servers, whereas rebooting usually takes a long time (we have thousands
   of servers).  It's a very bad experience for the users.  So we need a
   approach to enable this feature after rebooting.  This is a use case in
   our practical environment.

2) Some use cases are that HugeTLB pages are allocated 'on the fly'
   instead of being pulled from the HugeTLB pool, those workloads would be
   affected with this feature enabled.  Those workloads could be
   identified by the characteristics of they never explicitly allocating
   huge pages with 'nr_hugepages' but only set 'nr_overcommit_hugepages'
   and then let the pages be allocated from the buddy allocator at fault
   time.  We can confirm it is a real use case from the commit
   099730d67417.  For those workloads, the page fault time could be ~2x
   slower than before.  We suspect those users want to disable this
   feature if the system has enabled this before and they don't think the
   memory savings benefit is enough to make up for the performance drop.

3) If the workload which wants vmemmap pages to be optimized and the
   workload which wants to set 'nr_overcommit_hugepages' and does not want
   the extera overhead at fault time when the overcommitted pages be
   allocated from the buddy allocator are deployed in the same server. 
   The user could enable this feature and set 'nr_hugepages' and
   'nr_overcommit_hugepages', then disable the feature.  In this case, the
   overcommited HugeTLB pages will not encounter the extra overhead at
   fault time.

Link: https://lkml.kernel.org/r/20220512041142.39501-5-songmuchun@bytedance.com
Signed-off-by: Muchun Song 
Reviewed-by: Mike Kravetz 
Cc: Jonathan Corbet 
Cc: Luis Chamberlain 
Cc: Kees Cook 
Cc: Iurii Zaikin 
Cc: Oscar Salvador 
Cc: David Hildenbrand 
Cc: Masahiro Yamada 
Cc: Xiongchun Duan 
Signed-off-by: Andrew Morton

Documentation/sysctl: document page_lock_unfairness

2022-04-29T06:16:01+00:00

commit 5ef64cc8987a ("mm: allow a controlled amount of unfairness in the
page lock") introduced a new systctl but no accompanying documentation.

Add a simple entry to the documentation.

Link: https://lkml.kernel.org/r/20220325164437.120246-1-jsavitz@redhat.com
Signed-off-by: Joel Savitz 
Cc: Jonathan Corbet 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Dave Hansen 
Cc: Suren Baghdasaryan 
Cc: Mike Rapoport 
Cc: "zhangyi (F)" 
Cc: Charan Teja Reddy 
Cc: Linus Torvalds 
Signed-off-by: Andrew Morton

mm/pagealloc: sysctl: change watermark_scale_factor max limit to 30%

2022-01-15T14:30:29+00:00

For embedded systems with low total memory, having to run applications
with relatively large memory requirements, 10% max limitation for
watermark_scale_factor poses an issue of triggering direct reclaim every
time such application is started.  This results in slow application
startup times and bad end-user experience.

By increasing watermark_scale_factor max limit we allow vendors more
flexibility to choose the right level of kswapd aggressiveness for their
device and workload requirements.

Link: https://lkml.kernel.org/r/20211124193604.2758863-1-surenb@google.com
Signed-off-by: Suren Baghdasaryan 
Acked-by: Johannes Weiner 
Cc: Michal Hocko 
Cc: Lukas Middendorf 
Cc: Antti Palosaari 
Cc: Luis Chamberlain 
Cc: Kees Cook 
Cc: Iurii Zaikin 
Cc: Dave Hansen 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Jonathan Corbet 
Cc: Zhang Yi 
Cc: Fengfei Xi 
Cc: Mike Rapoport 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: compaction: support triggering of proactive compaction by user

2021-09-03T16:58:17+00:00

The proactive compaction[1] gets triggered for every 500msec and run
compaction on the node for COMPACTION_HPAGE_ORDER (usually order-9) pages
based on the value set to sysctl.compaction_proactiveness.  Triggering the
compaction for every 500msec in search of COMPACTION_HPAGE_ORDER pages is
not needed for all applications, especially on the embedded system
usecases which may have few MB's of RAM.  Enabling the proactive
compaction in its state will endup in running almost always on such
systems.

Other side, proactive compaction can still be very much useful for getting
a set of higher order pages in some controllable manner(controlled by
using the sysctl.compaction_proactiveness).  So, on systems where enabling
the proactive compaction always may proove not required, can trigger the
same from user space on write to its sysctl interface.  As an example, say
app launcher decide to launch the memory heavy application which can be
launched fast if it gets more higher order pages thus launcher can prepare
the system in advance by triggering the proactive compaction from
userspace.

This triggering of proactive compaction is done on a write to
sysctl.compaction_proactiveness by user.

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=facdaa917c4d5a376d09d25865f5a863f906234a

[akpm@linux-foundation.org: tweak vm.rst, per Mike]

Link: https://lkml.kernel.org/r/1627653207-12317-1-git-send-email-charante@codeaurora.org
Signed-off-by: Charan Teja Reddy 
Acked-by: Vlastimil Babka 
Acked-by: Rafael Aquini 
Cc: Mike Rapoport 
Cc: Luis Chamberlain 
Cc: Kees Cook 
Cc: Iurii Zaikin 
Cc: Dave Hansen 
Cc: Mel Gorman 
Cc: Nitin Gupta 
Cc: Jonathan Corbet 
Cc: Khalid Aziz 
Cc: David Rientjes 
Cc: Vinayak Menon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds