| Age | Commit message (Collapse) | Author |
|---|
|
damos_quota_goal->complement needs to be manually set by each API
callers. It is easy to make mistakes. Extend the quota goal
constructor, damos_new_quota_goal() to receive and set the complement
flag value. Also update all callers to use the new signature.
Link: https://lore.kernel.org/20260929080113.41708-3-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
|
|
Patch series "mm/damon: introduce damos quota goal target metric
complement flag".
Aim-oriented DAMOS quota auto-tuning assumes the aggressiveness of the
scheme (quota) and the quota goal metric are directly proportional.
Depending on the scheme setup and usage, keeping the relationship can be
challenging.
For example, let's suppose a memory tiering approach for higher upper tier
utilization. One common idea for that (TPP) is utilizing two schemes, one
for promotion and the other one for demotion. The promotion scheme
migrates hot pages from lower tier to upper tier, aiming for high
utilization of the upper tier. The demotion scheme migrates cold pages
from upper tier to lower tier, aiming for head room free memory of the
upper tier. Both schemes and their goals are in direct proportion.
However, for this kind of use case, we need to implement two different
goal metrics (per-node memory utilization and free memory ratio) while
essentially the free memory ratio is just a complemented value of the
utilization.
To avoid adding too many new metrics, we are adding metrics that turn out
to be really needed for each found use case. For example,
some_mem_psi_us, node_eligible_mem_bp and hugepage_mem_bp don't have their
complemented value version. But it is not really difficult to expect use
cases that their complemented version can be useful. For example,
hugepage_mem_bp use case may need a way to reduce the hugepage ratio.
That would require a complemented version of hugepage_mem_bp. Adding a
new metric for each of such use cases could make the number of metrics
unnecessarily high, and discourage flexible usages of DAMOS.
Add a new flag, quota goal complement, to allow flexible tuning goal setup
without unnecessarily increasing the number of metrics. The flag
specifies whether to use the complemented value of the given goal metric
for the tuning. For example, if the complement flag is set, the upper
tier memory utilization ratio metric works the same as the free memory
ratio metric for the tier.
This patch (of 8):
Introduce damos_quota_goal->complement for specifying whether to use a
complemented value of the given goal target metric. Add the field to
the data structure and implement essential core support. Handle the
flag in the quota goal commit and current quota goal metric value
retrieval.
Link: https://lore.kernel.org/20260929080113.41708-1-sj@kernel.org
Link: https://lore.kernel.org/20260929080113.41708-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Gutierrez Asier <gutierrez.asier@huawei-partners.com>
|
|
Patch series "mm/damon/core: cleanup code, reduce stack usage, and add
kunit".
Three various improvements. Patch 1 from Zenghui Yu (Huawei) cleans up
unused enums. Patch 2 from Arnd Bergmann reduces kdamond's stack usage.
Patch 3 from Karl Mehltretter adds a kunit test for uninitialized PSI
quota goal stage logic.
This patch (of 3):
NR_DAMOS_ACTIONS, NR_DAMOS_QUOTA_GOAL_METRICS, and NR_DAMOS_WMARK_METRICS
are not referenced by any code. Remove them.
They can be reintroduced if a real user comes up.
Link: https://lore.kernel.org/20260928083959.4030-1-sj@kernel.org
Link: https://lore.kernel.org/20260928083959.4030-2-sj@kernel.org
Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
|
|
damon_set_attrs() accepts sample_interval == 0. This was reported as a
bug in v1 of this patch (rejecting it in damon_set_attrs()). A similar
patch was already declined for the same reason: a zero interval is
intentionally supported [1].
Document the behavior instead of changing it.
Link: https://lore.kernel.org/20260921151547.78472-5-sj@kernel.org
Link: https://lore.kernel.org/all/20260722094304.3132750-1-dayou5941@163.com/ [1]
Signed-off-by: Karthikeyan KS <karthiproffesional@gmail.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: Adrian Huang <adrianhuang0701@gmail.com>
Cc: Liew Rui Yan <aethernet65535@gmail.com>
Cc: Xuewen Wang <wangxuewen@kylinos.cn>
Cc: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
|
|
Patch series "mm/damon: improve readability, clarity and test coverage".
Yet another batch of miscellaneous DAMON minor improvements. Mostly
focused on readability and clarity of code and document, and unit/self
test coverage. No user-visible behavioral change is intended.
This patch (of 10):
Nobody uses NR_DAMOS_FILTER_TYPES. Remove it.
Link: https://lore.kernel.org/20260917142210.90829-1-sj@kernel.org
Link: https://lore.kernel.org/20260917142210.90829-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@davidgow.net>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Patch series "mm/damon: introduce hugepage_size probe filter".
Knowing whether a given memory is backed by a hugepage of specific size
is useful for efficient utilization of hugepages. For easy monitoring
of the information, introduce a new data attribute probe filter type,
hugepage_size. It works similar to the DAMOS filter of the same name.
It works for memory that is backed by a hugepage of a given size range.
Patch 1 introduces the new probe filter type to DAMON API and extends
related data structures. Patch 2 updates probe filter commit logic to
handle the size range. Patch 3 Updates the filtering logic to support
the new type. Patch 4 adds new DAMON sysfs files for the size range.
Patch 5 updates DAMON sysfs interface to fully support the new filter
type. Patches 6-8 updates design, usage and ABI documents for the new
feature.
This patch (of 8):
Introduce a new data attribute probe filter type, hugepage_size. It will
work for memory that is backed by a hugepage of a given size range. Add a
new damon_filter_type enum DAMON_FILTER_TYPE_HUGEPAGE_SIZE to identify the
type. Add two new fields in the damon_filter struct for saving the size
range.
Link: https://lore.kernel.org/20260915143359.91472-1-sj@kernel.org
Link: https://lore.kernel.org/20260915143359.91472-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
damon_probe_hits_wsum() is being called only in aggregation time. In
future, it could also be used by DAMOS. In this case, since DAMOS uses
its own apply_interval, it could be called in sampling time. Then using
the not yet fully aggregated probe_hits could result in suboptimum
outcomes. Extend damon_probe_hits_wsum() to get the weighted sum based on
moving sum to prepare the DAMOS usage.
Link: https://lore.kernel.org/20260911135510.96914-3-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Patch series "mm/damon: introduce probe_hits_wsum DAMOS core filter", v2.
DAMON can do flexible data attributes monitoring. The classical data
access monitoring can also be done using the attributes monitoring. The
access event is just one of the data attributes that DAMON supports.
Users do monitoring to make some actions based on it. DAMOS is a feature
for automating that. However, DAMOS cannot utilize the data attributes
monitoring results. It is still Data "Access" Monitoring-based Operation
Schemes. It requires users to set the target "access" pattern.
DAMOS core filter is effectively the same as the target access pattern.
It is just a more generalized and flexible way of describing the operation
action target region. Introduce a new DAMOS core filter type,
probe_hits_wsum. It specifies the filter target based on a range of the
probe hits weighted sum. Using this, users can apply DAMOS actions to
regions of specific data attributes pattern.
Note that the classic target access pattern still works. Hence the target
nr_accesses range should still be properly configured. The new filter
would be used in only data attributes-only mode. In the mode, classic
access monitoring is just turned off, and therefore nr_accesses of regions
are always zero. Users could simply set the target nr_accesses range to
include the zero nr_Accesses regions.
Patches Sequence
================
Patch 1 updates the DAMON kernel API for the new filter type. Patch 2
extends damon_probe_hits_wsum() to do the calculation based on moving sum.
Patch 3 implements the filter type in the core layer. Patch 4 refactors
DAMON sysfs interface internal data structure for efficient reuse of data
structure for the probe hits weighted sum range user inputs. Patch 5
updates DAMON sysfs interface to support the new filter type. Patches 6
and 7 update design and usage documents for the new filter type,
respectively.
This patch (of 7):
Update DAMON kernel API to introduce new DAMOS core filter type,
PROBE_HITS_WSUM. It will allow API callers to describe the DAMOS action
target regions based on their probe_hits weighted sum. For describing the
filtering target weighted sum range, add two type-dependent union fields
to damos_filter.
[sj@kernel.org: clarify DAMOS_FILTER_TYPE_PROBE_HITS_WSUM behavior]
Link: https://lore.kernel.org/20260911142522.98013-1-sj@kernel.org
Link: https://lore.kernel.org/20260911135510.96914-1-sj@kernel.org
Link: https://lore.kernel.org/20260911135510.96914-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Patch series "mm/damon: introduce pgidle_set probe filter type".
Users can do effective access monitoring with DAMON, using set_pgidle
probe prep operation and pgidle_unset allowing probe filter. In the
setup, high probe_hits means the region was accessed frequently. Zero
probe_hits means the region was not accessed. The filter, however,
matches only the memory that can show the idleness. Regions of zero
probe_hits may contain memory that was just unable to show the idleness.
On virtual address space based monitoring, for example, non-present pages
are reported as cold. It is truly cold, but if the purpose is to make
some operations like reclaiming or compressing the data, this is not
really useful. Introduce a new probe filter type, pgidle_set, that
confirms the page is marked as idle. Using it instead of pgidle_unset,
users can find cold pages that can effectively be processed.
Patch 1 introduces the pgidle_set probe filter type to DAMON kernel API.
Patches 2 and 3 add support for it on physical and virtual address space
operation sets, respectively. Patch 4 adds support for it on the DAMON
sysfs interface. Finally, patch 5 updates the documentation for the new
filter type.
This patch (of 5):
DAMON_FILTER_TYPE_PGIDLE_UNSET matches only memory that was able to
confirm if it is marked as idle. If the memory cannot be marked as idle,
it simply doesn't match. Hence, finding memory that was marked as idle
with only DAMON_FILTER_TYPE_PGIDLE_UNSET is impossible. Introduce a new
filter for the purpose, DAMON_FILTER_TYPE_PGIDLE_SET.
Link: https://lore.kernel.org/20260910142234.171562-1-sj@kernel.org
Link: https://lore.kernel.org/20260910142234.171562-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
damon_prep needs to be executed by the underlying DAMON operation set.
Extend the operation set callback list for the execution of damon_prep
actions. If the underlying operation set implements the callback, DAMON
core executes it in the monitoring preparation time.
Link: https://lore.kernel.org/20260901132506.99243-8-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Some DAMON probe filter types require preparatory actions. For example,
pgilde_unset probe filter can say if the page was accessed but when. To
answer the second question, the PG_Idle flag should be set at a specific
time. It can make life much easier if DAMON can do such preparatory
actions. Introduce a new data type called damon_prep. It specifies each
of the preparation actions for each probe. DAMON will execute the action
for each region per sampling interval, like it clears page table accessed
bits and unsets PG_Idle flag for access monitoring.
Also introduce DAMON_PREP_SET_PGIDLE as the initial prep action. As the
name says, it will do exactly what DAMON was doing as the preparation
action for the access monitoring.
Link: https://lore.kernel.org/20260901132506.99243-6-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Patch series "mm/damon: introduce data access-as-a-data attribute", v1.1.
TL;DR: extend DAMON's data attributes monitoring system to support page
table accessed bit and PG_idle based access monitoring.
DAMON was initially introduced as a data access monitor. Users found data
access pattern becomes more useful when it is combined with other data
attributes such as belonging cgroups and backing page types. For such
cases, DAMON has extended to support such data attributes monitoring in
addition to the original data access monitoring. The DAMON probes system
was introduced for this purpose. Users set probes for filtering data
attributes of their interest. For use cases where the primary interests
are the attributes but the access pattern, probe weights system has been
introduced. When it is used, DAMON applies its adaptive regions
adjustment based on the monitored data attributes.
However, DAMON stops access monitoring when the probe weights are used.
DAMON cannot optimally help users who have interests in both data
attributes and access patterns. Data access can also be thought of as
another data attribute, though. Extend the probe system to support data
access as a data attribute.
Introduce a new probe filter type, pgidle_unset. It shows if the page is
not set as idle. Specifically, it shows the page table accessed bit and
the PG_idle flag. It can inform if the region is ever accessed. But it
cannot say when it is accessed. To answer the second question, introduce
a new probe feature, prep actions. Using the features, Users can specify
what preparation actions should be made to each region for each probe.
DAMON executes the preparation actions for each sampling interval, like it
is doing the preparation for access check in the access monitoring mode.
To help 'pgidle_unset' probe action use case, 'set_pgidle' preparation
action is introduced together. The action does exactly what the access
monitoring was doing: clearing the page table accessed bits and setting
the PG_idle flags.
Tests
=====
I compared the access pattern monitoring results from the classic way and
the probe based way. As expected, the probe based way shows the results
similar to that of the classic way. More detailed test methods and
results are below.
First, do the access monitoring using the DAMON user-space tool [1] in the
classic way. The system is idle. It shows no access as expected.
$ sudo ./damo/damo start
$ sudo ./damo/damo report access
heatmap:
00000000000000000000000000000000000000008999999811111110000000000000000000000000
# min/max temperatures: -640,000,000, -100,000,000, column size: 99.800
MiB
intervals: sample 5 ms aggr 100 ms (max access hz 200)
0 addr 4.000 KiB size 3.898 GiB access 0 hz age 6.400 s
1 addr 3.898 GiB size 787.301 MiB access 0 hz age 1 s
2 addr 4.667 GiB size 773.457 MiB access 0 hz age 5.800 s
3 addr 5.423 GiB size 2.374 GiB access 0 hz age 6.400 s
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
Start an artificial memory access generator (masim) [2] in another window.
$ ./masim/masim.py run --config_file ./masim/configs/zigzag.cfg
Show the monitoring results. As expected, it captures accesses.
$ sudo ./damo/damo report access
heatmap:
00000000000000000000000000000000000000011111111111111118888888833378988888888888
# min/max temperatures: -1,470,000,000, -12,482,536, column size: 99.800
MiB
intervals: sample 5 ms aggr 100 ms (max access hz 200)
0 addr 4.000 KiB size 1.542 GiB access 0 hz age 14.700 s
1 addr 1.542 GiB size 788.324 MiB access 0 hz age 14.600 s
2 addr 2.311 GiB size 772.844 MiB access 0 hz age 14.200 s
[...]
50 addr 6.839 GiB size 1.742 MiB access 0 hz age 1.300 s
51 addr 6.840 GiB size 8.000 KiB access 100 hz age 0 ns
52 addr 6.840 GiB size 1.496 MiB access 160 hz age 0 ns
[...]
97 addr 7.162 GiB size 1.199 MiB access 40 hz age 400 ms
98 addr 7.163 GiB size 1.199 MiB access 20 hz age 400 ms
99 addr 7.164 GiB size 2.004 MiB access 160 hz age 0 ns
100 addr 7.166 GiB size 646.004 MiB access 0 hz age 400 ms
memory bw estimate: 26.148 GiB per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
After the artificial memory access generator (masim) is terminated,
restart DAMON with the probe-based access monitoring. As expected, it
shows no access since the system is idle again.
$ sudo ./damo/damo stop
$ sudo ./damo/damo start --probe_prep set_pgidle \
--probe_filter allow pgidle_unset --probe_weight 1
$ sudo ./damo/damo report attrs
heatmap:
00000000000000000000000000000000000000008999999711111100000000000000000000000000
# min/max temperatures: -600,000,000, -430,000,000, column size: 99.800
MiB
probe prep: set_pgidle, filter: allow pgidle_unset (weight: 1)
intervals: sample 5 ms aggr 100 ms (max probe hits 20)
# addr size age probe_hits
0 4.000 KiB 3.898 GiB 6 s 0
1 5.285 GiB 2.512 GiB 6 s 0
2 4.659 GiB 641.816 MiB 5.700 s 0
3 3.898 GiB 778.375 MiB 4.300 s 0
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
Start the artificial memory access generator [2] again.
$ ./masim/masim.py run --config_file ./masim/configs/zigzag.cfg
Show the monitoring results. As expected, it captures accesses similar to
the classic monitoring mode.
$ sudo ./damo/damo report attrs
heatmap:
00000000000000000000000000000000000000011111110000000177777777777777878798887777
# min/max temperatures: -1,330,000,000, 84,847,514, column size: 99.800
MiB
probe prep: set_pgidle, filter: allow pgidle_unset (weight: 1)
intervals: sample 5 ms aggr 100 ms (max probe hits 20)
# addr size age probe_hits
0 4.000 KiB 1.508 GiB 13.300 s 0
1 1.508 GiB 794.684 MiB 13.200 s 0
2 2.284 GiB 764.555 MiB 13 s 0
[...]
50 6.711 GiB 4.625 MiB 0 ns 17
51 6.716 GiB 2.504 MiB 0 ns 17
52 6.732 GiB 796.000 KiB 0 ns 17
[...]
90 7.162 GiB 512.000 KiB 2.200 s 2
91 7.061 GiB 700.000 KiB 2.300 s 1
92 6.935 GiB 316.000 KiB 2.300 s 4
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
Patches Sequence
================
First four patches (patches 1-4) introduce the new probe filter type for
knowing if a region is accessed. Patch 1 defines the new type in the
core. Patch 2 implements the execution of the new filter in the physical
address space DAMON operation set. Patch 3 implements a user interface on
DAMON sysfs interface. Patch 4 updates the documentation for the new
filter type.
Following 13 patches (patches 5-17) introduce the probe preparation
actions feature. Patch 5 defines the data structure for specifying the
preparation actions. Patch 6 completes setup of the API parameter for the
prep. Patch 7 extends the DAMON operation set callback list to connect
the parameter with the underlying operation set. Patch 8 implements the
execution of the prep in the physical address space DAMON operation set.
Following five patches (patches 9-13) extends DAMON sysfs interface for
the new prep feature. Patch 14 adds simple selftest for basic file
operations of the new sysfs files. Final three patches (patches 15-17)
respectively update design, usage and ABI documents for the new feature
and its interface.
This patch (of 17):
Introduce a new DAMON filter type, pgidle_unset. It will match pages that
have their PG_Idle flag unset, or the page table accessed bit set. In
other words, it says if the page is accessed.
Link: https://lore.kernel.org/20260901132506.99243-1-sj@kernel.org
Link: https://lore.kernel.org/20260901132506.99243-2-sj@kernel.org
Link: https://github.com/damonitor/damo [1]
Link: https://github.com/sjp38/masim [2]
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
The logic that finds the struct pid for a given pid number and assigns it
to a damon_target is duplicated in multiple places. Including
damon_sysfs_add_target() of mm/damon/sysfs.c and the start functions of
the two sample modules, samples/damon/wsse.c and samples/damon/prcl.c.
Add a function that does the work, and replace the duplicated code in the
places with calls to the function.
Link: https://lore.kernel.org/20260831142611.77572-3-sj@kernel.org
Signed-off-by: Enze Li <lienze@kylinos.cn>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hari Mishal <harimishal1@gmail.com>
Cc: Jaeyeon Lee <jaeyeon.lee.dev@gmail.com>
Cc: Li Youhong <liyouhong@kylinos.cn>
Cc: Shuah Khan <shuah@kernel.org>
Cc: "Zenghui Yu (Huawei)" <zenghui.yu@linux.dev>
Cc: zhaozhengzhuo <zhaozhengzhuo@uniontech.com>
|
|
Patch series "mm/damon: Introduce a huge page collapsing mechanism using
auto tuning", v4.
Overview
========
This patchset introduces a new autotuning which allows to collapse hot
regions into hugepages.
Motivation
==========
Since TLB is a bottleneck for many systems[1], a way to optimize TLB
misses (or hits) is to use huge pages. Unfortunately, using "always" in
THP leads to memory fragmentation and memory waste. For this reason, most
application guides and system administrators suggest to disable THP.
Selective huge page collapse per process is possible using prctl and a
launcher. However, this does not solve the issue with hot region
detection. Additionally, it the sysadmin should create a launcher that
uses PRCTL to enable THP for a particular process.
We can use the DAMON support for DAMOS_HUGEPAGE and DAMOS_COLLAPSE, to
target a certain process. DAMOS_COLLAPSE can also target the hot regions
in that process.
Still, there is an issue with the amount of huge page consumption. Since
huge pages can lead to memory fragmentation and waste, there should be a
way to limit the amount of huge page consumption. There is hugetlbfs, but
it requires changes to the application code or the use of libhugetlbfs.
DAMON has now a way to autotune some of the variables and adjust quotas
automatically, so that DAMON is fired only under the right circumstances.
It would be nice to have something similar, but for huge pages.
Solution
========
A new autotuning quota goal[2], damos_hugepage_mem_bp, is introduced,
which checks the huge page consumption to total memory consumption. This
new quota mechanism reuses current autotuning architecture.
In order to test this new mechanism, a sample module[3] was created, but
not included in this patch series. To demonstrate the tool, damo user
space tool was modified[4], which sets up huge pages collapse autotuning.
Benchmarks
==========
Setup: physical server with arm64 processor with 4 NUMA nodes, 1 TB RAM
and running mariaDB 10.5.29. Sysbench was used for the benchmark, with 20
tables and 3 million rows per table. The database was pinned to one of
the nodes, and the benchmark framework to a different node. No network
traffic involved in the benchmark.
Damo user space tool was forked and hugepage_mem_bp support added[4].
DAMON was lauched using this command line:
sudo ./damo start $(pidof mariadbd) \
--monitoring_nr_regions_range 10 1000 \
--monitoring_intervals 5000 100000 60000000 \
--damos_quota_time 0 --damos_quota_space 128000000 \
--damos_quota_interval 1000 \
--damos_quota_weights 0 1 1 \
--damos_quota_goal hugepage_mem_bp <target> \
--damos_quota_goal_tuner temporal \
--damos_apply_interval 50000 \
--damos_access_rate 0 max --damos_age 50 max \
--damos_action collapse --debug_damon
<target> was 1000 to taget 10% hugepage to total memory ratio, or 2500 to
target 25%. Tuner was also tested with consistent and temporal.
Results
=======
After the last timestamp, there was no change in huge page use, and the
total huge page to memory consumption ratio barely moved.
hugepage_mem_bp: 1000
goal tuner: temporal
+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+----------------------+
| 0 | 16945.04297 | 0 | 0 |
| 7 | 17008.69531 | 74 | 0.435071583 |
| 8 | 17036.40234 | 194 | 1.138738074 |
| 9 | 17017.01563 | 314 | 1.845211916 |
| 10 | 17029.67969 | 434 | 2.548491856 |
| 61 | 17111.30859 | 584 | 3.412947623 |
| 120 | 17071.05859 | 694 | 4.065360072 |
| 180 | 17133.88281 | 804 | 4.692456513 |
| 203 | 17088.16406 | 916 | 5.360435426 |
| 204 | 17126.34766 | 1046 | 6.107548562 |
| 205 | 17093.84375 | 1176 | 6.879669764 |
| 206 | 17142.77734 | 1298 | 7.571701913 |
| 209 | 17149.17969 | 1686 | 9.831374041 |
| 210 | 17097.30859 | 1754 | 10.25892462 |
+-----------+----------------+----------------+----------------------+
hugepage_mem_bp: 1000
goal tuner: consistent
+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+----------------------+
| 0 | 16955.24609 | 0 | 0 |
| 34 | 17039.71875 | 106 | 0.622075995 |
| 78 | 17009.47656 | 554 | 3.257007927 |
| 90 | 17048.92188 | 596 | 3.495822225 |
| 150 | 17092.90625 | 706 | 4.130368409 |
| 180 | 17053.08984 | 764 | 4.480126517 |
| 233 | 17100.50391 | 1496 | 8.748280216 |
| 239 | 17098.89063 | 2216 | 12.95990511 |
| 240 | 17135.44531 | 2334 | 13.62088908 |
| 245 | 17132.55078 | 2932 | 17.11362212 |
| 246 | 17117.95313 | 3052 | 17.82923448 |
| 250 | 17163.12109 | 3532 | 20.57900763 |
+-----------+----------------+----------------+----------------------+
hugepage_mem_bp: 2500
goal tuner: temporal
+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+----------------------+
| 0 | 17010.31641 | 0 | 0 |
| 9 | 17063.6875 | 50 | 0.2930199 |
| 10 | 17051.75781 | 170 | 0.996964664 |
| 60 | 17133.85547 | 572 | 3.338419663 |
| 90 | 17192.07813 | 626 | 3.641211932 |
| 120 | 17221.44531 | 682 | 3.960178647 |
| 181 | 17199.76172 | 790 | 4.593086886 |
| 208 | 17222.77734 | 1206 | 7.002354939 |
| 214 | 17245.17969 | 1904 | 11.04076637 |
| 215 | 17240.45703 | 2024 | 11.73982799 |
| 220 | 17234.79688 | 2624 | 15.22501262 |
| 228 | 17222.83594 | 3584 | 20.80958103 |
| 231 | 17247.55469 | 3944 | 22.86700968 |
| 235 | 17229.37109 | 4424 | 25.67708349 |
+-----------+----------------+----------------+----------------------+
hugepage_mem_bp: 1000
goal tuner: consist
+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+----------------------+
| 0 | 17125.85156 | 0 | 0 |
| 38 | 17081.23438 | 76 | 0.444932716 |
| 39 | 17133.11719 | 196 | 1.143983304 |
| 40 | 17119.83984 | 316 | 1.84581166 |
| 60 | 17109.72656 | 554 | 3.237924335 |
| 90 | 17164.11328 | 628 | 3.65879664 |
| 180 | 17177.66016 | 792 | 4.610639591 |
| 220 | 17180.86719 | 1378 | 8.020549749 |
| 226 | 17187.82031 | 1980 | 11.51978531 |
| 233 | 17143.48438 | 2818 | 16.4377319 |
| 240 | 17137.38281 | 3656 | 21.33347921 |
| 250 | 17175.5 | 4856 | 28.27283049 |
| 260 | 17199.66406 | 6056 | 35.20999002 |
| 270 | 17203.98438 | 7254 | 42.16465118 |
| 275 | 17207.21875 | 7762 | 45.10897498 |
+-----------+----------------+----------------+----------------------+
More detailed tables are provided here[5]
From this, we can conclude that the huge page autotuner works fine,
achieving the target. When using consistent autotuner, it actually
over-achieves the target, which is expected, since quota esz_bp is not set
to 0 to cap the DAMOS policy.
Patches Sequence
================
Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
Patch 2 -> sysfs support for the new quota goal
Patch 3 -> Document hugepage_mem_bp parameter
This patch (of 3):
Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP auto tuning. Add a new DAMOS quota
goal metric to measure the amount of huge page consumption to total memory
consumption ratio.
Vmstat may lag, which in some cases may lead to NR_FREE_PAGES being
greater than or equal to the amount of RAM in the system. A guard is
added to avoid the extremely unlikely case [6]. In the case, return 100%
(10000 bp).
Link: https://lore.kernel.org/20260831144732.80910-1-sj@kernel.org
Link: https://lore.kernel.org/20260831144732.80910-2-sj@kernel.org
Link: https://dl.acm.org/doi/pdf/10.1145/3307650.3322227 [1]
Link: https://lore.kernel.org/e67f05ad-dbb9-45e6-ba30-b167a99ac67d@huawei-partners.com [2]
Link: https://lore.kernel.org/20260616150316.580819-3-gutierrez.asier@huawei-partners.com [3]
Link: https://github.com/asierHuawei/damo/commit/79ae1a4ab1c012a7161db85a000d14f08fa36736 [4]
Link: https://lore.kernel.org/all/03f678dd-9ef3-4b97-b753-c2e4554c5159@huawei-partners.com/ [5]
Link: https://lore.kernel.org/all/20260715151615.99767-1-sj@kernel.org/ [6]
Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
damon_nr_running_ctxs() has had no in-tree users since commit 5ec4333b1967
("mm/damon: remove DAMON debugfs interface") removed all of its callers.
Remove the unused declaration and definition.
Link: https://lore.kernel.org/20260831145724.82387-3-sj@kernel.org
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
|
|
Patch series "mm/damon/core: remove unused helper functions", v2.
Both damon_targets_empty() and damon_nr_running_ctxs() have had no in-tree
users since commit 5ec4333b1967 ("mm/damon: remove DAMON debugfs
interface") removed their remaining callers.
Remove the unused declarations and definitions.
This patch (of 2):
damon_targets_empty() has had no in-tree users since commit 5ec4333b1967
("mm/damon: remove DAMON debugfs interface") removed its last caller.
Remove the unused declaration and definition.
Link: https://lore.kernel.org/20260831145724.82387-1-sj@kernel.org
Link: https://lore.kernel.org/20260831145724.82387-2-sj@kernel.org
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
|
|
Fix a typo (nr_snapshots -> max_nr_snapshots) and corrects a grammar
error.
Link: https://lore.kernel.org/20260831150227.83416-4-sj@kernel.org
Signed-off-by: Liew Rui Yan <aethernet65535@gmail.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
Patch series "docs/mm/damon/design: add explanation of nr_snapshots", v3.
Add an explanation of nr_snapshots to avoid misunderstandings.
This patch (of 3):
Change "tried to be applied" -> "completely tried to be applied" to
maintain consistency between the documentation and the code.
Link: https://lore.kernel.org/20260831150227.83416-1-sj@kernel.org
Link: https://lore.kernel.org/20260831150227.83416-2-sj@kernel.org
Signed-off-by: Liew Rui Yan <aethernet65535@gmail.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
|
|
The kernel-doc comment above enum damos_filter_type states that only the
anon and memcg type filters are handled by damon_operations (and therefore
accounted as 'tried'), and that DAMON_OPS_VADDR and DAMON_OPS_FVADDR do
not support those two filter types.
Neither is accurate anymore. damos_filter_for_ops() routes every filter
type except ADDR and TARGET to the operations layer, and the VADDR and
FVADDR operations (the latter being a copy of the former) handle all of
those types through damos_folio_filter_match() / damos_va_filter_out().
Update the comment to match the code.
Link: https://lore.kernel.org/20260721140011.269802-1-sj@kernel.org
Signed-off-by: Song Hu <husong@kylinos.cn>
Reviewed-by: SJ Park <sj@kernel.org>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
'ops', 'probes', 'adaptive_targets', 'schemes', and 'rnd_state' fields of
damon_ctx are intended to be used by only the DAMON core layer. However,
those are mistakenly not marked as private. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-11-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
'filters' and 'list' fields of damon_probe are intended to be used by only
the DAMON core layer. However, those are mistakenly not marked as
private. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-9-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damon_filter->list is intended to be used by only the DAMON core layer.
However, it is mistakenly not marked as private. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-8-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
'core_filters', 'ops_filters', 'last_applied' and 'list' fields of damos
are intended to be used by only the DAMON core layer. However, those are
mistakenly not marked as private. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-7-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damos_filter->list is intended to be used by only the DAMON core layer.
However, it is mistakenly not marked as private. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-6-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damos_quota->goals is intended to be used by only the DAMON core layer.
But it is mistakenly not marked as private. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-5-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
'last_psi_total' and 'list' of damos_quota_goal are intended to be used by
only the DAMON core layer. Those are mistakenly not marked as private,
though. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-4-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
'nr_regions', 'regions_list' and 'list' fields of damon_target are
intended to be used by only the DAMON core layer. Those are mistakenly
not marked as private. Mark as private.
Link: https://lore.kernel.org/20260714143544.101305-3-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Patch series "mm/damon/core: hide core-private struct fields".
DAMON core structs hide core-private fields using 'private:' comment tags.
It is incomplete and inconsistent. The linked list heads in a few
structs, for example, are intended to be hidden, and always be used using
the wrapper macros like damon_for_each_region(). But those were
mistakenly marked as non-private. A few core layer-only fields were also
mistakenly added as non-private.
This only encourages callers to directly use the private fields. It is
easy to make mistakes, and difficult to control. Mark all such DAMON core
struct fields as private.
Patches 1-8 mark the private fields for damon_region, damon_target,
damos_quota_goal, damos_quota, damos_filter, damos, damon_filter and
damon_probe, respectively. Patch 9 removes DAMON_SYSFS's direct access to
core-private field, damon_ctx->ops. Finally patch 10 mark the private
fields for damon_ctx.
This patch (of 10):
damon_region->list is intended to be used by only the DAMON core layer.
But it is mistakenly not marked as private. Hide it from the callers by
marking it private.
Link: https://lore.kernel.org/20260714143544.101305-1-sj@kernel.org
Link: https://lore.kernel.org/20260714143544.101305-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
When damon_probe->weight is set, the weighted sum of probe hits will be
useful. It will be useful for not only the users but also DAMON internal
logics like regions merging. Implement a function for calculating it.
Link: https://lore.kernel.org/20260710134651.18084-6-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
check_accesses() DAMON ops callback returns the maximum nr_accesses of
regions. DAMON core uses it to calculate a reasonable region merge
threshold. The core will need to adjust regions for not nr_accesses but
probe hits weighted sum in future. For that, the core needs to know the
maximum weighted sum of the regions. Update the protocol for the task.
Link: https://lore.kernel.org/20260710134651.18084-5-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
prepare_access_checks() DAMON ops callback sets the monitoring sampling
address per region. In future, DAMON will be able to call only
apply_probes(). In this case, applyy_probes() may need to do the sampling
address setup, to minimize unnecessary regions iteration. Update the
protocol for the request.
Link: https://lore.kernel.org/20260710134651.18084-3-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Patch series "mm/damon: introduce data attributes only monitoring".
TL;DR: Introduce a way to get DAMON's best effort accuracy monitoring of
user-demanding non-access data attributes.
Background
==========
DAMON was initially designed for only access monitoring. It turned out
users want to get the information together with more data attributes. For
example, some users want to know how much of a hot memory region belongs
to huge pages or specific cgroups. Page level properties based monitoring
was introduced with commit 626ffabe67c2 ("mm/damon: clarify trying vs
applying on damos_stat kernel-doc comment") to fill the gap. Because it
works only at snapshot level and snapshot capturing in the mode can induce
high overhead, commit 45c49d9fd608 ("mm/damon/core: introduce struct
damon_probe") introduced data attributes monitoring.
Data attributes monitoring treats the attributes as only additional and
subordinate information. Data access monitoring is always turned on, and
regions are adjusted for best accuracy of the access information. In some
cases, users may be primarily interested in the attributes more than the
access. They might even not care about the access information at all.
Because DAMON treats data accesses as the only primary information, such
users cannot get high quality attributes information.
Design and Implementation
=========================
Introduce another way for treating data attributes as the primary
information. Add 'weight' property to each data attribute probe. When
any of the weights are set, the mode is enabled. Data access monitoring
is completely turned off in the mode. For region adjustment, the weighted
sum of probe hit counters is used instead of the nr_accesses.
Using the weights, users can specify to what attributes they are
interested in to what degree. DAMON will adjust the regions and provide
the best-effort quality monitoring that is optimized for the user demands.
Extend damon_operations for efficient use of probe hits. Update regions
merge and kdamond main logic to support the new mode. Add a new struct
field and a sysfs file for API callers and ABI users, respectively.
Test
====
On ~7 GiB memory idle system, run a simple AI-assisted program. The
program allocates and faults 2 GiB anonymous pages. Then, it does nothing
but wait until the user terminates it. Hence, the system ~2 GiB of
anonymous pages with no active accesses.
Monitor the distribution of the anonymous pages using DAMON attributes
monitoring mode, using DAMON user-space tool, damo [1].
$ sudo ./damo start --probe_filter allow anon
$ sudo ./damo report access --dont_merge_regions
heatmap: 00000000000000000000000000000000000000000000000399999995111111146666666666666666
# min/max temperatures: -2,470,000,000, -1,620,000,000, column size: 99.800 MiB
intervals: sample 5 ms aggr 100 ms (max access hz 200)
# <start> <size> <freq> <age> <probe hits>
0 4.000 KiB 79.840 MiB 0 hz 24.700 s 2
1 79.844 MiB 718.562 MiB 0 hz 24.700 s 8
2 798.406 MiB 793.148 MiB 0 hz 24.700 s 7
3 1.554 GiB 797.828 MiB 0 hz 24.700 s 7
4 2.333 GiB 794.668 MiB 0 hz 24.600 s 8
5 3.109 GiB 791.117 MiB 0 hz 24.500 s 0
6 3.882 GiB 785.312 MiB 0 hz 24 s 2
7 4.649 GiB 787.867 MiB 0 hz 16.200 s 6
8 5.418 GiB 784.477 MiB 0 hz 23.300 s 6
9 6.184 GiB 783.820 MiB 0 hz 18.200 s 9
10 6.950 GiB 797.730 MiB 0 hz 18.900 s 7
11 7.729 GiB 69.625 MiB 0 hz 18.900 s 0
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
Note that the line after the line starting with "intervals:" is not
provided by the current version of 'damo'. I manually added the legends
line for easier understanding of these results.
Each of the 12 lines after the legend line shows the DAMON-found regions.
Each line shows 1) index of the region, 2) start address of the region, 3)
size of the region, 4) access frequency of the region, 5) age (how long
the access frequency on the region was kept) of the region, and finally 6)
the probe hit count.
Because data access is the primary information that adjusts region for,
and there is only nearly zero access on the system, regions are naively
adjusted with the same size. Still <probe hits> show different
distribution of the anonymous pages, but it is obviously very rough
information.
Switch to the attributes only mode and show how it changes the picture:
$ sudo ./damo tune --probe_filter allow anon --probe_weight 100
$ sudo ./damo report access --dont_merge_regions
heatmap: 88888888888888888889888999999889999999000004888888888888889999988888898888888888
# min/max temperatures: -4,430,000,000, 0, column size: 99.800 MiB
intervals: sample 5 ms aggr 100 ms (max access hz 200)
# <start> <size> <freq> <age> <probe hits>
0 4.000 KiB 60.445 MiB 0 hz 700 ms 0
1 60.449 MiB 1.363 MiB 0 hz 600 ms 18
2 61.812 MiB 144.000 KiB 0 hz 0 ns 1
3 61.953 MiB 1.922 MiB 0 hz 2.400 s 19
4 63.875 MiB 12.133 MiB 0 hz 200 ms 0
[...]
500 5.132 GiB 8.000 KiB 0 hz 2 m 15.800 s 20
501 5.132 GiB 8.000 KiB 0 hz 2 m 16.200 s 0
502 5.132 GiB 16.000 KiB 0 hz 2 m 16.900 s 20
503 5.132 GiB 24.000 KiB 0 hz 2 m 14.200 s 0
504 5.132 GiB 8.000 KiB 0 hz 2 m 14.900 s 20
[...]
923 7.534 GiB 126.637 MiB 0 hz 0 ns 6
924 7.658 GiB 252.000 KiB 0 hz 54.800 s 20
925 7.658 GiB 142.242 MiB 0 hz 300 ms 0
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
As expected, regions are adjusted to provide the best accurate picture for
the anonymous pages distribution (<probe hits>). The region 0 (60.445 MiB
memory from the address 4.000 KiB) has nearly zero anonymous pages. The
region 1 (1.363 MiB memory from the address 60.449 MiB) is nearly full
with anonymous pages. Region 500 (8 KiB memory from the address 5.132
GiB) is certainly two anonymous pages.
Future Work
===========
Attributes only monitoring disables access monitoring. We will enable
that in future, by extending the supported attributes to include data
accesses. This patch series, and the future work are parts of the ongoing
project [2] for extending DAMON. The project aims to extend DAMON with
primitives other than page table accessed bits such as AMD IBS, Intel
PEBS, and Arm SPE, to provide more powerful and detailed information like
per-CPUs/threads/reads/writes monitoring.
Patches Sequence
================
Patch 1 introduces damon_probe->weight for specifying the weights of each
attribute. Patches 2-6 extends apply_probe() damon_ops callback to
efficiently support the new mode. Patch 7 fixes wrong use of abs() in the
regions merge code. Patch 8 extends regions merge function to work with
probe hits in the mode. Patch 8 also introduces the function for
detecting the mode enablement but always returns false, for safe and
incremental changes. Patches 9 and 10 adds user parameters validation to
prevent theoretical overflow of probe hits and the weighted sum. Patches
11-14 incrementally update kdamond_fn() to support the mode. Patch 15
completes the mode detection function implementation, so that the new mode
really works. Patch 16 introduces a new sysfs file for ABI users.
Finally, patches 17-19 respectively updates design, usage and ABI
documents for the new feature and interfaces.
[1] https://github.com/damonitor/damo
[2] https://lore.kernel.org/20260525225208.1179-1-sj@kernel.org/
This patch (of 19):
Add a new field, weight to damon_probe struct. The field is used to
specify the degree of the API caller's interest to the data attribute of
the probe.
Link: https://lore.kernel.org/20260710134651.18084-1-sj@kernel.org
Link: https://lore.kernel.org/20260710134651.18084-2-sj@kernel.org
Link: https://github.com/damonitor/damo [1]
Link: https://lore.kernel.org/20260525225208.1179-1-sj@kernel.org/ [2]
Signed-off-by: SJ Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damon_max_nr_accesses() actually returns the number of samples DAMON
checks for each region per each aggregation interval. Rename it to better
describe what it really does and not confusing for more general uses.
Link: https://lore.kernel.org/20260708135359.122587-3-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damon_stop() always returns 0, and nobody cares. Change the return type
to void.
Link: https://lore.kernel.org/20260706140628.87414-8-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
The kernel doc comment of damon_region clearly specifies every region
should have positive size. But it is unclear who should verify it.
damon_set_regions() is the recommended DAMON core function for setting
regions from the callers, and has the verification. Update the comment to
clarify the callers should be ok to pass any values for region addresses,
as long as they use damon_set_regions().
Link: https://lore.kernel.org/20260705155600.96555-7-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Implement a function for getting a reasonable best effort quality pseudo
moving sums of probe_hits on demands. It reuses the internal function for
the pseudo moving sum for data access frequency (nr_accesses).
Link: https://lore.kernel.org/20260703170605.94472-3-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Patch series "mm/damon: provide pseudo moving sum probe_hits".
Data attribute counters (probe_hits) of DAMON are managed in the classical
way. The counter value is accumulated every sampling interval, gets the
complete view at the end of the aggregation interval, and is reset when
the next aggregation interval starts. Hence, the complete view can be
retrieved only once per aggregation interval, which can be quite long.
With the suggested intervals autotuning setup, it becomes 2-4 seconds in
common real production systems. It can span up to 200 seconds in theory.
This will restrict online monitoring use case of DAMON.
Actually DAMON is already providing online monitoring of probe_hits.
DAMON sysfs interface exposes the values via schemes tried regions
directory files. However, due to the above mentioned limitation, it
usually shows only partially accumulated hit counters and therefore not
useful.
DAMOS is not using probe_hits at the moment. In the future, using it can
further strengthen DAMOS. However, a recommended setup of DAMOS is
utilizing sampling/aggregation intervals auto-tuning, and having its own
DAMOS apply_interval (1 second is mostly recommended). In the setup,
DAMOS will nearly always show incompletely accumulated probe_hits, which
will not really be useful.
Data frequency counter (nr_accesses) of DAMON solves this problem using
the pseudo moving sum value. The infrastructure is not limited to
nr_accesses but general sampling based counters. Maintain and provide the
pseudo moving sum of probe_hits similar to nr_accesses, using the
infrastructure.
Tests
=====
On an idle system, I ran DAMON with an attribute probe filter for
non-anonymous page, using DAMON user-space tool, damo [1], like below.
$ sudo ./damo start --probe_filter allow non anon
Because the system is idle, nearly all memory is not an anonymous page but
a free page, so the probe_hits are expected to be nearly always full. In
this setup, since the sampling interval is 5ms and the aggregation
interval is 100ms, the counter value is expected to always be near 20.
On kernels not having this series, if we retrieve the probe hits in an
arbitrary time that is likely not aligned to the aggregation interval, the
values are usually much lower than the expectation like below. This is
because the tool is showing the incompletely aggregated values.
$ sudo ./damo report access --format append region "probe_hits: <probe hits>"
heatmap: 00000000000000000000000000000000000000008999999711111111000000000000000000000000
# min/max temperatures: -1,630,000,000, 0, column size: 99.800 MiB
intervals: sample 5 ms aggr 100 ms (max access hz 200)
0 addr 4.000 KiB size 3.898 GiB access 0 hz age 16.300 s probe_hits: 11
1 addr 3.898 GiB size 77.859 MiB access 0 hz age 1.500 s probe_hits: 11
2 addr 3.974 GiB size 700.770 MiB access 0 hz age 0 ns probe_hits: 11
3 addr 4.659 GiB size 791.078 MiB access 0 hz age 13.700 s probe_hits: 11
4 addr 5.431 GiB size 1.472 GiB access 0 hz age 15.800 s probe_hits: 11
5 addr 6.903 GiB size 915.059 MiB access 0 hz age 15.300 s probe_hits: 11
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
After applying this series, I was able to reliably show the expected
results like below.
$ sudo ./damo report access --format append region "probe_hits: <probe hits>"
heatmap: 00000000333333330000000166666665111111139999999855555555333333333333333444444444
intervals: sample 5 ms aggr 100 ms (max access hz 200)
0 addr 4.000 KiB size 790.496 MiB access 0 hz age 1 m 33.300 s probe_hits: 20
1 addr 790.500 MiB size 791.160 MiB access 0 hz age 1 m 15.400 s probe_hits: 19
2 addr 1.545 GiB size 792.316 MiB access 0 hz age 1 m 32.400 s probe_hits: 19
3 addr 2.318 GiB size 795.465 MiB access 0 hz age 1 m 2.600 s probe_hits: 19
4 addr 3.095 GiB size 797.102 MiB access 0 hz age 1 m 23.500 s probe_hits: 20
5 addr 3.874 GiB size 797.293 MiB access 0 hz age 47.900 s probe_hits: 20
6 addr 4.652 GiB size 787.516 MiB access 0 hz age 1 m 3.800 s probe_hits: 20
7 addr 5.421 GiB size 784.461 MiB access 0 hz age 1 m 14.400 s probe_hits: 19
8 addr 6.187 GiB size 795.621 MiB access 0 hz age 1 m 15.700 s probe_hits: 20
9 addr 6.964 GiB size 798.000 MiB access 0 hz age 1 m 10.200 s probe_hits: 20
10 addr 7.744 GiB size 54.566 MiB access 0 hz age 1 m 9.300 s probe_hits: 20
memory bw estimate: 0 B per second
total size: 7.797 GiB
record DAMON intervals: sample 5 ms, aggr 100 ms
FYI, 'damo report access' output format has changed on v3.3.0. Above
outputs can be reproduced on <3.3.0 versions of damo.
Patches Sequence
================
Patch 1 adds probe_hits counters for values that fully accumulated in the
last aggregation interval. This is required for using the moving sum
infrastructure. Patch 2 introduces a function for getting the moving sum
values on demand, using the infrastructure. Finally, patch 3 updates the
DAMON sysfs interface to expose the moving sum values to the schemes tried
regions directory.
This patch (of 3):
Add new damon_region filed, last_probe_hits. Maintain fully accumulated
probe_hits values from the last aggregation interval in the field.
Link: https://lore.kernel.org/20260703170605.94472-1-sj@kernel.org
Link: https://lore.kernel.org/20260703170605.94472-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
No code touches damon_region->nr_accesses_bp field. Remove it.
Link: https://lore.kernel.org/20260630040812.149729-19-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damon_update_region_access_rate() is not using attrs parameter. Remove
it.
Link: https://lore.kernel.org/20260630040812.149729-15-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Patch series "mm/damon: optimize out nr_accesses_bp".
TLDR: Replace damon_region->nr_accesses_bp, which is easy to be wrong,
with a simpler on-demand moving sum function, damon_nr_accesses_mvsum().
Background
==========
DAMON's monitoring output (access pattern snapshot, or more technically
speaking, damon_region->nr_accesses) is completed once per aggregation
interval, which is 100 ms by default. Users can arbitrarily increase the
interval for demand. Under the suggested intervals auto-tuning setup, it
can span up to 200 seconds. If the aggregation interval is too long, the
snapshot users cannot use it in reasonable time. To mitigate this, we
introduced a new field of damon_region, namely nr_accesses_bp. It
contains a pseudo moving sum of nr_accesses in bp units and is updated for
each sampling interval.
It turned out keeping it correctly updated every sampling interval is not
that easy. From online parameter update feature development and more
experimental hacks, we found it is easy to be corrupted. Once it is
corrupted, DAMON's monitoring outputs become quite insane. Hence we added
a few validation checks. It is easy to be corrupted because it requires
every update per sampling interval to be correct.
Solution
========
There is no real reason to keep it updated every sampling interval. Due
to the simple pseudo-moving sum mechanism and existing helper field
(last_nr_accesses), we can also calculate the pseudo moving sum on demand
in a much simpler way.
Implement a function for getting the pseudo moving sum on demand, and
replace nr_accessses_bp uses with the new function. Also remove no more
needed tests for nr_accesses_bp and the per-sampling interval update
functions. Finally, remove the nr_accesses_bp. The new function is quite
simple.
Discussion
==========
Depending on the use case, multiple nr_accesses readers could be executed
in the same kdamond_fn() main loop iteration, which is executed once per
sampling interval. Such readers include DAMON region exporting
tracepoints (damon_[region_]aggregated and damos_before_apply), DAMOS, and
DAMON sysfs interface logic for update_schemes_tried_regions command. In
this case, the new function will be called multiple times and this could
be overhead compared to the old logic, which simply reads the field
without any additional work. Nonetheless, the new function is quite
simple. And the new approach does nothing while there is no need to read.
The old approach had to execute its update function for each region for
every sampling interval. Hence the new approach is believed to be even
more lightweight in common case, and the overhead is anyway negligible.
One more advantage of this change is that one field from the damon_region
struct is removed. On setups that uses a high number of DAMON regions,
this could be a potential memory space benefit.
Patches Sequence
================
Patch 1 introduces the new function for getting the pseudo moving sum of
nr_accesses on demands. Patch 2 implements a unit test for the new
function's internal logic. Patch 3 and 4 update monitoring logic and the
new function to ready for safe use on the existing logic. Patches 5-7
replace uses of nr_accesses_bp in DAMOS, tracepoints and DAMON sysfs
interface with the new function, respectively. Patches 8-10 removes
nr_accesses_bp validation functions in DAMON core, one by one. Patches 11
and 12 further remove tests and test helper for nr_accesses_bp,
respectively. Patches 13 removes the setups and updates or nr_accesses_bp
field. Patches 14-16 cleans up function parameters that are no more being
used due to the previous patch. Patch 17 removes the function that was
used for updating nr_accesses_bp field with its unit test, which is the
single remaining caller of the function. Finally, patch 18 removes
damon_region->nr_accesses_bp field.
This patch (of 18):
Introduce a new DAMON core function, damon_nr_accesses_mvsum(). It
returns a pseudo moving sum value of a given region's nr_accesses for the
last aggregation interval. The internal logic is the same to
nr_accesses_bp. The difference is that nr_accesses_bp is updated for each
sampling interval, while the new function needs to be executed only when
requested. Hence the function's return value is the same as the value of
nr_accesses_bp.
Link: https://lore.kernel.org/20260630040812.149729-1-sj@kernel.org
Link: https://lore.kernel.org/20260630040812.149729-2-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
My legal and preferred first names are SeongJae and SJ, respectively. I
was using the legal name for commits and tags, while using the preferred
name for conversations. It sometimes confuses people including myself.
Consistently use the preferred name.
Together remove copyright notes on files. Those are only confusing for
people who are not familiar with the law. Meanwhile, we can infer the
information in a better way from git logs and public information.
Link: https://lore.kernel.org/20260630013820.143366-1-sj@kernel.org
Signed-off-by: SJ Park <sj@kernel.org>
Acked-by: Lorenzo Stoakes <ljs@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Fix below kernel document build warning:
WARNING: ../include/linux/damon.h:909 struct member 'rnd_state' not described in 'damon_ctx'
Link: https://lore.kernel.org/20260628220808.98931-3-sj@kernel.org
Fixes: 9012c4e647df ("mm/damon: replace damon_rand() with a per-ctx lockless PRNG")
Signed-off-by: SJ Park <sj@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/4df95955-b255-4e5a-90c4-35db02f3111f@infradead.org
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
The two fields of damon_ctx struct dont have their kernel-doc comments.
That causes kernel document builds to warn. Fix those.
This patch (of 2):
Fix below document build warning:
WARNING: ../include/linux/damon.h:909 struct member 'probes' not described in 'damon_ctx'
Link: https://lore.kernel.org/20260628220808.98931-1-sj@kernel.org
Link: https://lore.kernel.org/20260628220808.98931-2-sj@kernel.org
Fixes: 18c777859f28 ("mm/damon/core: embed damon_probe objects in damon_ctx")
Signed-off-by: SJ Park <sj@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/4df95955-b255-4e5a-90c4-35db02f3111f@infradead.org
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Fix three issues in damon_hot_score() that comes from wrong handling of
extreme (zero or too high) monitoring intervals user setup.
When the user sets sampling interval zero, damon_max_nr_accesses(), which
is called from damon_hot_score(), causes a divide-by-zero. Needless to
say, it is a problem.
When the user sets the aggregation interval zero, the function returns
zero. It is wrong, since the real maximum nr_acceses in the setup should
be one. Worse yet, it can cause another divide-by-zero from its caller,
damon_hot_score(), since it uses damon_max_nr_accesses() return value as a
denominator.
When the user sets the aggregation interval very high, damon_hot_score()
could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return
value is used as an index to the regions_score_histogram array, which is
DAMOS_MAX_SCORE+1 size, it causes out of bounds array access.
The issues can be relatively easily reproduced like below. The sysfs
write permission is required, though.
# ./damo start --damos_action lru_prio --damos_quota_space 100M \
--damos_quota_interval 1s
# cd /sys/kernel/mm/damon/admin/kdamonds/0
# echo 0 > contexts/0/monitoring_attrs/intervals/sample_us
# echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us
# echo commit > state
# dmesg
[...]
[ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI
[...]
[ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0
[...]
Fix the divide-by-zero intervals problems by explicitly handling the zero
intervals in damon_max_nr_accesses(). Fix the out-of-bound array access
by applying [0, DAMOS_MAX_SCORE] bounds before returning from
damon_hot_score().
The issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/20260623135834.67189-1-sj@kernel.org
Link: https://lore.kernel.org/20260619202459.145010-1-sj@kernel.org [1]
Fixes: 198f0f4c58b9 ("mm/damon/vaddr,paddr: support pageout prioritization")
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org> # 5.16.x
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Patch series "mm/damon: fix macro arguments and clarify quota goals doc",
v2.
This patch (of 2):
The DAMON iterator macros do not wrap their pointer arguments with
parentheses. This can cause build failures when the argument is a complex
expression due to operator precedence issues.
Add missing parentheses around the arguments in the following macros
to prevent potential build failures:
- damon_for_each_region()
- damon_for_each_region_from()
- damon_for_each_region_safe()
- damos_for_each_quota_goal()
Link: https://lore.kernel.org/20260521202020.126500-1-maksym.shcherba@lnu.edu.ua
Link: https://lore.kernel.org/20260521202020.126500-2-maksym.shcherba@lnu.edu.ua
Signed-off-by: Maksym Shcherba <maksym.shcherba@lnu.edu.ua>
Reviewed-by: SeongJae Park <sj@kernel.org>
Assisted-by: Antigravity:Gemini-3.1-Pro
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damon_destroy_region() is being used by only DAMON core, but exposed to
DAMON API callers. Exposing something that is not really being used by
others will only increase the maintenance cost. Hide it.
Link: https://lore.kernel.org/20260522154026.80546-8-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damon_insert_region() is being used by only DAMON core, but exposed to
DAMON API callers. Exposing something that is not really being used by
others will only increase the maintenance cost. Hide it.
Link: https://lore.kernel.org/20260522154026.80546-7-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
damon_add_region() is being used by only DAMON core, but exposed to DAMON
API callers. Exposing something that is not really being used by others
will only increase the maintenance cost. Hide it.
Link: https://lore.kernel.org/20260522154026.80546-6-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Find and set the memcg_id for damon_filter from the user-passed memory
cgroup path when updating the DAMON input parameters.
Link: https://lore.kernel.org/20260518234119.97569-27-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
Belonging memory cgoup is another data attribute that can be useful to
monitor. Introduce a new DAMON filter type, namely
DAMON_FILTER_TYPE_MEMCG, for monitoring of this attribute.
Link: https://lore.kernel.org/20260518234119.97569-23-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
