diff options
Diffstat (limited to 'Documentation/mm')
| -rw-r--r-- | Documentation/mm/damon/design.rst | 25 | ||||
| -rw-r--r-- | Documentation/mm/damon/maintainer-profile.rst | 10 | ||||
| -rw-r--r-- | Documentation/mm/memory-model.rst | 2 | ||||
| -rw-r--r-- | Documentation/mm/page_owner.rst | 32 | ||||
| -rw-r--r-- | Documentation/mm/process_addrs.rst | 9 |
5 files changed, 62 insertions, 16 deletions
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index 80354f4f42ba..2d8d8ca1e0a3 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -381,8 +381,8 @@ That is, assumes 4% (20% of 20%) DAMON-observed access events ratio (source) to capture 64% (80% multipled by 80%) real access events (outcomes). To know how user-space can use this feature via :ref:`DAMON sysfs interface -<sysfs_interface>`, refer to :ref:`intervals_goal <sysfs_scheme>` part of -the documentation. +<sysfs_interface>`, refer to :ref:`intervals_goal +<damon_usage_sysfs_monitoring_intervals_goal>` part of the documentation. .. _damon_design_damos: @@ -564,9 +564,9 @@ aggressiveness (the quota) of the corresponding scheme. For example, if DAMOS is under achieving the goal, DAMOS automatically increases the quota. If DAMOS is over achieving the goal, it decreases the quota. -The goal can be specified with four parameters, namely ``target_metric``, -``target_value``, ``current_value`` and ``nid``. The auto-tuning mechanism -tries to make ``current_value`` of ``target_metric`` be same to +The goal can be specified with five parameters, namely ``target_metric``, +``target_value``, ``current_value``, ``nid`` and ``path``. The auto-tuning +mechanism tries to make ``current_value`` of ``target_metric`` be same to ``target_value``. - ``user_input``: User-provided value. Users could use any metric that they @@ -581,9 +581,18 @@ tries to make ``current_value`` of ``target_metric`` be same to set by users at the initial time. In other words, DAMOS does self-feedback. - ``node_mem_used_bp``: Specific NUMA node's used memory ratio in bp (1/10,000). - ``node_mem_free_bp``: Specific NUMA node's free memory ratio in bp (1/10,000). - -``nid`` is optionally required for only ``node_mem_used_bp`` and -``node_mem_free_bp`` to point the specific NUMA node. +- ``node_memcg_used_bp``: Specific cgroup's node used memory ratio for a + specific NUMA node, in bp (1/10,000). +- ``node_memcg_free_bp``: Specific cgroup's node unused memory ratio for a + specific NUMA node, in bp (1/10,000). + +``nid`` is optionally required for only ``node_mem_used_bp``, +``node_mem_free_bp``, ``node_memcg_used_bp`` and ``node_memcg_free_bp`` to +point the specific NUMA node. + +``path`` is optionally required for only ``node_memcg_used_bp`` and +``node_memcg_free_bp`` to point the path to the cgroup. The value should be +the path of the memory cgroup from the cgroups mount point. To know how user-space can set the tuning goal metric, the target value, and/or the current value via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst index 58a3fb3c5762..e761edada1e9 100644 --- a/Documentation/mm/damon/maintainer-profile.rst +++ b/Documentation/mm/damon/maintainer-profile.rst @@ -27,8 +27,8 @@ maintainer. Note again the patches for `mm-new tree <https://git.kernel.org/akpm/mm/h/mm-new>`_ are queued by the memory management -subsystem maintainer. If the patches requires some patches in `damon/next tree -<https://git.kernel.org/sj/h/damon/next>`_ which not yet merged in mm-new, +subsystem maintainer. If the patches require some patches in `damon/next tree +<https://git.kernel.org/sj/h/damon/next>`_ which have not yet merged in mm-new, please make sure the requirement is clearly specified. Submit checklist addendum @@ -57,7 +57,7 @@ Key cycle dates Patches can be sent anytime. Key cycle dates of the `mm-new <https://git.kernel.org/akpm/mm/h/mm-new>`_, `mm-unstable -<https://git.kernel.org/akpm/mm/h/mm-unstable>`_and `mm-stable +<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ and `mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>`_ trees depend on the memory management subsystem maintainer. @@ -99,5 +99,5 @@ Schedules and reservation status are available at the Google `doc <https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`_. There is also a public Google `calendar <https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>`_ -that has the events. Anyone can subscribe it. DAMON maintainer will also -provide periodic reminder to the mailing list (damon@lists.linux.dev). +that has the events. Anyone can subscribe to it. DAMON maintainer will also +provide periodic reminders to the mailing list (damon@lists.linux.dev). diff --git a/Documentation/mm/memory-model.rst b/Documentation/mm/memory-model.rst index 5f3eafbbc520..7957122039e8 100644 --- a/Documentation/mm/memory-model.rst +++ b/Documentation/mm/memory-model.rst @@ -165,7 +165,7 @@ The users of `ZONE_DEVICE` are: * pmem: Map platform persistent memory to be used as a direct-I/O target via DAX mappings. -* hmm: Extend `ZONE_DEVICE` with `->page_fault()` and `->page_free()` +* hmm: Extend `ZONE_DEVICE` with `->page_fault()` and `->folio_free()` event callbacks to allow a device-driver to coordinate memory management events related to device-memory, typically GPU memory. See Documentation/mm/hmm.rst. diff --git a/Documentation/mm/page_owner.rst b/Documentation/mm/page_owner.rst index 3a45a20fc05a..6b12f3b007ec 100644 --- a/Documentation/mm/page_owner.rst +++ b/Documentation/mm/page_owner.rst @@ -27,7 +27,10 @@ enabled. Other usages are more than welcome. It can also be used to show all the stacks and their current number of allocated base pages, which gives us a quick overview of where the memory is going without the need to screen through all the pages and match the -allocation and free operation. +allocation and free operation. It's also possible to show only a numeric +identifier of all the stacks (without stack traces) and their number of +allocated base pages (faster to read and parse, eg, for monitoring) that +can be matched with stacks later (show_handles and show_stacks_handles). page owner is disabled by default. So, if you'd like to use it, you need to add "page_owner=on" to your boot cmdline. If the kernel is built @@ -116,6 +119,33 @@ Usage nr_base_pages: 20824 ... + cat /sys/kernel/debug/page_owner_stacks/show_handles > handles_7000.txt + cat handles_7000.txt + handle: 42 + nr_base_pages: 20824 + ... + + cat /sys/kernel/debug/page_owner_stacks/show_stacks_handles > stacks_handles.txt + cat stacks_handles.txt + post_alloc_hook+0x177/0x1a0 + get_page_from_freelist+0xd01/0xd80 + __alloc_pages+0x39e/0x7e0 + alloc_pages_mpol+0x22e/0x490 + folio_alloc+0xd5/0x110 + filemap_alloc_folio+0x78/0x230 + page_cache_ra_order+0x287/0x6f0 + filemap_get_pages+0x517/0x1160 + filemap_read+0x304/0x9f0 + xfs_file_buffered_read+0xe6/0x1d0 [xfs] + xfs_file_read_iter+0x1f0/0x380 [xfs] + __kernel_read+0x3b9/0x730 + kernel_read_file+0x309/0x4d0 + __do_sys_finit_module+0x381/0x730 + do_syscall_64+0x8d/0x150 + entry_SYSCALL_64_after_hwframe+0x62/0x6a + handle: 42 + ... + cat /sys/kernel/debug/page_owner > page_owner_full.txt ./page_owner_sort page_owner_full.txt sorted_page_owner.txt diff --git a/Documentation/mm/process_addrs.rst b/Documentation/mm/process_addrs.rst index be49e2a269e4..7f2f3e87071d 100644 --- a/Documentation/mm/process_addrs.rst +++ b/Documentation/mm/process_addrs.rst @@ -48,7 +48,8 @@ Terminology * **VMA locks** - The VMA lock is at VMA granularity (of course) which behaves as a read/write semaphore in practice. A VMA read lock is obtained via :c:func:`!lock_vma_under_rcu` (and unlocked via :c:func:`!vma_end_read`) and a - write lock via :c:func:`!vma_start_write` (all VMA write locks are unlocked + write lock via vma_start_write() or vma_start_write_killable() + (all VMA write locks are unlocked automatically when the mmap write lock is released). To take a VMA write lock you **must** have already acquired an :c:func:`!mmap_write_lock`. * **rmap locks** - When trying to access VMAs through the reverse mapping via a @@ -907,3 +908,9 @@ Stack expansion Stack expansion throws up additional complexities in that we cannot permit there to be racing page faults, as a result we invoke :c:func:`!vma_start_write` to prevent this in :c:func:`!expand_downwards` or :c:func:`!expand_upwards`. + +------------------------ +Functions and structures +------------------------ + +.. kernel-doc:: include/linux/mmap_lock.h |