mm/damon: misc fixups and improvements for 6.18
Subsystems (4)
SeongJae Park
maintainercover mm/damon: misc fixups and improvements for 6.18
Misc fixes and improvements for DAMON that are not critical and therefore aims to be merged into Linux 6.18-rc1.
The first patch improves DAMON's age counting for nr_accesses zero to/from non-zero changes.
The second patch fixes an initial DAMOS apply interval delay issue that is not realistic but still could happen on an odd setup.
The third patch fixes wrongly written code that doesn't cause any real problem but could make code review confusing.
The fourth and the fifth patches update DAMON community meetup description and DAMON user-space tool example command for DAMOS usage, respectively.
Finally, the sixth patch updates MAINTAINERS section name for DAMON to just DAMON.
Changes from RFC
(https://lore.kernel.org/[email protected])
- The RFC was only for the first patch
- Rebase and wordsmith the first patch
- Add a few misc fixes and improvements for 6.18 to the series
SeongJae Park (6):
mm/damon/core: reset age if nr_accesses changes between non-zero and
zero
mm/damon/core: set effective quota on first charge window mm/damon/lru_sort: use param_ctx correctly Docs/mm/damon/maintainer-profile: update community meetup for
reservation requirements
Docs/admin-guide/mm/damon/start: add --target_pid to DAMOS example
command
MAINTAINERS: rename DAMON section
Documentation/admin-guide/mm/damon/start.rst | 2 +- Documentation/mm/damon/maintainer-profile.rst | 17 ++++++----------- MAINTAINERS | 2 +- mm/damon/core.c | 7 ++++++- mm/damon/lru_sort.c | 2 +- 5 files changed, 15 insertions(+), 15 deletions(-)
base-commit: d245e17d619ea0336d50b0a6c914f5701d1b0e53
Signature · 1 line
2.39.5
SeongJae Park
maintainerPATCH 1/6 mm/damon/core: reset age if nr_accesses changes between non-zero and zero
DAMON resets the age of a region if its nr_accesses value has significantly changed. Specifically, the threshold is calculated as 20% of largest nr_accesses of the current snapshot. This means that regions changing the nr_accesses from zero to small non-zero value or from a small non-zero value to zero will keep the age. Since many users treat zero nr_accesses regions special, this can be confusing. Kernel code including DAMOS' regions priority calculation and DAMON_STAT's idle time calculation also treat zero nr_accesses regions special. Make it unconfusing by resetting the age when the nr_accesses changes between zero and a non-zero value.
--- mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+)
mm/damon/core.c +3 -0
@@ -2261,6 +2261,9 @@ static void damon_merge_regions_of(struct damon_target *t, unsigned int thres,damon_for_each_region_safe (r, next, t) {if (abs (r->nr_accesses - r->last_nr_accesses) > thres) r->age =0 ; +else if ((!r->nr_accesses && r->last_nr_accesses) || + (r->nr_accesses && !r->last_nr_accesses)) + r->age =0 ;else r->age++;
Signature · 1 line
2.39.5
Re: [PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero
Quoted 10 lines · On Sun, 14 Sep 2025 18:58:02 -0700 SeongJae Park <[email protected]> wrote:
DAMON resets the age of a region if its
nr_accessesvalue has significantly changed. Specifically, the threshold is calculated as 20% of largestnr_accessesof the current snapshot. This means that regions changing thenr_accessesfrom zero to small non-zero value or from a small non-zero value to zero will keep the age. Since many users treat zeronr_accessesregions special, this can be confusing. Kernel code including DAMOS' regions priority calculation and DAMON_STAT's idle time calculation also treat zeronr_accessesregions special. Make it unconfusing by resetting the age when thenr_accesseschanges between zero and a non-zero value.
Hi SJ,
Thank you for the patch, I think the goal of the patch makes sesne to me. I have a small nit / idea which I think makes the code a bit clearer, at least for me. It seems that we basically want to XOR the two values's zero-ness, so maybe something like
(!!r->nr_accesses) ^ (!!r->last_nr_access) or
(r->nr_accesses == 0) ^ (r->last_nr_access == 0)
Can achieve the goal? I know bitwise operations are sometimes harder to understand, so I am just throwing the idea out there : -)
Anyways, the rest of it looks good to me, please feel free to add my review!
Quoted 21 lines
Signed-off-by SeongJae Park <[email protected]>--- mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+)mm/damon/core.c +3
-0@@ -2261,6 +2261,9 @@ static void damon_merge_regions_of(struct damon_target *t, unsigned int thres,damon_for_each_region_safe (r, next, t) {if (abs (r->nr_accesses - r->last_nr_accesses) > thres) r->age =0 ; +else if ((!r->nr_accesses && r->last_nr_accesses) || + (r->nr_accesses && !r->last_nr_accesses)) + r->age =0 ;else r->age++;Signature · 1 line
2.39.5
Sent using hkml (https://github.com/sjp38/hackermail)
SeongJae Park
maintainerRe: [PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero
Quoted 20 lines · On Mon, 15 Sep 2025 07:51:57 -0700 Joshua Hahn <[email protected]> wrote:
Quoted 10 lines · On Sun, 14 Sep 2025 18:58:02 -0700 SeongJae Park <[email protected]> wrote:
DAMON resets the age of a region if its
nr_accessesvalue has significantly changed. Specifically, the threshold is calculated as 20% of largestnr_accessesof the current snapshot. This means that regions changing thenr_accessesfrom zero to small non-zero value or from a small non-zero value to zero will keep the age. Since many users treat zeronr_accessesregions special, this can be confusing. Kernel code including DAMOS' regions priority calculation and DAMON_STAT's idle time calculation also treat zeronr_accessesregions special. Make it unconfusing by resetting the age when thenr_accesseschanges between zero and a non-zero value.Hi SJ,
Thank you for the patch, I think the goal of the patch makes sesne to me. I have a small nit / idea which I think makes the code a bit clearer, at least for me. It seems that we basically want to XOR the two values's zero-ness, so maybe something like
Quoted 4 lines
(!!r->nr_accesses) ^ (!!r->last_nr_access) or
(r->nr_accesses== 0) ^ (r->last_nr_access== 0)Can achieve the goal?
Thank you for the idea, this makes sense!
Quoted 2 lines
I know bitwise operations are sometimes harder to understand, so I am just throwing the idea out there : -)
To be honest I'm one of people who are not familiar with XOR. I had to spend a minute to understand the above. Maybe we can replace '^' with '!=', and it is easier to read for me. If you don't mind, I will use below in the next version:
else if ((r->nr_accesses == 0) != (r->last_nr_accesses == 0))
Please let me know if I'm missing something or you have other opinions.
Quoted 5 lines
Anyways, the rest of it looks good to me, please feel free to add my review!
Reviewed-by Joshua Hahn <[email protected]>
Thank you!
Quoted 20 lines
Quoted 20 lines
Signed-off-by SeongJae Park <[email protected]>--- mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+)mm/damon/core.c +3
-0@@ -2261,6 +2261,9 @@ static void damon_merge_regions_of(struct damon_target *t, unsigned int thres,damon_for_each_region_safe (r, next, t) {if (abs (r->nr_accesses - r->last_nr_accesses) > thres) r->age =0 ; +else if ((!r->nr_accesses && r->last_nr_accesses) || + (r->nr_accesses && !r->last_nr_accesses)) + r->age =0 ;else r->age++;
Quoted 4 lines
Quoted 2 lines
Signature · 1 line
2.39.5Sent using hkml (https://github.com/sjp38/hackermail)
Thanks,
SJ
[...]
Andrew Morton
maintainerRe: [PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero
Quoted 15 lines · On Mon, 15 Sep 2025 11:26:51 -0700 SeongJae Park <[email protected]> wrote:
Quoted 9 lines
Thank you for the patch, I think the goal of the patch makes sesne to me. I have a small nit / idea which I think makes the code a bit clearer, at least for me. It seems that we basically want to XOR the two values's zero-ness, so maybe something like
(!!r->nr_accesses) ^ (!!r->last_nr_access) or
(r->nr_accesses== 0) ^ (r->last_nr_access== 0)Can achieve the goal?
Thank you for the idea, this makes sense!
Quoted 2 lines
I know bitwise operations are sometimes harder to understand, so I am just throwing the idea out there : -)
Quoted 8 lines
To be honest I'm one of people who are not familiar with XOR. I had to spend a minute to understand the above. Maybe we can replace '^' with '!=', and it is easier to read for me. If you don't mind, I will use below in the next version:
else if ((r->nr_accesses == 0) != (r->last_nr_accesses == 0))Please let me know if I'm missing something or you have other opinions.
I have to say, using xor as a shorthand for what-was-really-intended always bursts my brain. I have to stop, think about it and mentally turn the implementation back into what-was-really-intended. Maybe that's just me.
Ditto less-than-utterly-trivial :? expressions. Perhaps it's because if-then-else best suits how our minds work.
SeongJae Park
maintainerPATCH 2/6 mm/damon/core: set effective quota on first charge window
In reply to SeongJae ParkThe effective quota of a scheme is initialized zero, which means there is no quota. It is set based on user-specified time/quota/quota goals. But the later value set is done only from the second charge window. As a result, a scheme having a user-specified quota can work as not having the quota (unexpectedly fast) for the first charge window. In practical and common use cases the quota interval is not too long, and the scheme's target access pattern is restrictive. Hence the issue should be modest. That said, it is apparently an unintended misbehavior. Fix the problem by setting esz on the first charge window.
--- mm/damon/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
mm/damon/core.c +3 -1
@@ -2142,8 +2142,10 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)return ;/* First charge window */ -if (!quota->total_charged_sz && !quota->charged_from) +if (!quota->total_charged_sz && !quota->charged_from) { quota->charged_from = jiffies; +damos_set_effective_quota (quota); + }/* New charge window starts */ if (time_after_eq(jiffies, quota->charged_from +
Signature · 1 line
2.39.5
SeongJae Park
maintainerPATCH 3/6 mm/damon/lru_sort: use param_ctx correctly
In reply to SeongJae Parkdamon_lru_sort_apply_parameters() allocates a new DAMON context, stages user-specified DAMON parameters on it, and commits to running DAMON context at once, using damon_commit_ctx(). The code is, however, directly updating the monitoring attributes of the running context. This doesn't cause a real user problem but apparently this is an unintentional mistake that can cause code review confusions and future real problems. Fix the wrong use of the parameter context.
--- mm/damon/lru_sort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/damon/lru_sort.c +1 -1
@@ -219,7 +219,7 @@ static int damon_lru_sort_apply_parameters(void) goto out; } - err =damon_set_attrs (ctx, &damon_lru_sort_mon_attrs); + err =damon_set_attrs (param_ctx, &damon_lru_sort_mon_attrs);if (err) goto out;
Signature · 1 line
2.39.5
Re: [PATCH 3/6] mm/damon/lru_sort: use param_ctx correctly
Quoted 7 lines · On Sun, 14 Sep 2025 18:58:04 -0700 SeongJae Park <[email protected]> wrote:
damon_lru_sort_apply_parameters()allocates a new DAMON context, stages user-specified DAMON parameters on it, and commits to running DAMON context at once, usingdamon_commit_ctx(). The code is, however, directly updating the monitoring attributes of the running context. This doesn't cause a real user problem but apparently this is an unintentional mistake that can cause code review confusions and future real problems. Fix the wrong use of the parameter context.
Hi SJ,
Thank you for the patch! I am a little bit confused by the behavior in damon_lru_sort_apply_parameters. I was hoping that you could help me understand : -) In particular, I think that this patch fixes two possible user visible errors.
My understanding is that we want to make changes to the param_ctx first, validate the changes, and commit these changes to the global ctx struct at the end. In the middle in the errors, we can abort the operation without committing, and ctx will remain unchanged.
So to me, it does seem like the current code could lead to some visible effects from the user's perspective (error-handling case).
Also, I am a bit confused by how the commit is currently called. We have err = damon_commit_ctx(ctx, param_ctx), where the first argument is the destination and the second argument is the source. There is a bit of a mismatch because in the current code we have the following:
+------------------------------------------------+ | ctx param_ctx | +------------------------------------------------+ | New &damon_lru_sort_mon_attrs | | New scheme | | attrs overwritten to NULL <-- | | scheme rewritten to new scheme <-- | +------------------------------------------------+
So in particular, the global ctx will never have the correct attrs pre-patch, since it will always be rewritten by param_ctx, which never had its attrs initialized.
I hope this makes sense : -) All of this is just to say that this patch does more than just improve review confusions -- I think there at least two errors that this fixes for the user. So perhaps a more descriptive commit will be helpful in the future, since we are also adding a fixes tag?
Thank you again for the patch, SJ! Feel free to add:
Have a great day!
Joshua
Quoted 21 lines
Fixes a30969436428 ("mm/damon/lru_sort: use damon_commit_ctx()")Signed-off-by SeongJae Park <[email protected]>--- mm/damon/lru_sort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)mm/damon/lru_sort.c +1
-1@@ -219,7 +219,7 @@ static int damon_lru_sort_apply_parameters(void) goto out; } - err =damon_set_attrs (ctx, &damon_lru_sort_mon_attrs); + err =damon_set_attrs (param_ctx, &damon_lru_sort_mon_attrs);if (err) goto out;Signature · 1 line
2.39.5
Sent using hkml (https://github.com/sjp38/hackermail)
SeongJae Park
maintainerRe: [PATCH 3/6] mm/damon/lru_sort: use param_ctx correctly
Quoted 10 lines · On Mon, 15 Sep 2025 08:05:47 -0700 Joshua Hahn <[email protected]> wrote:
Quoted 7 lines · On Sun, 14 Sep 2025 18:58:04 -0700 SeongJae Park <[email protected]> wrote:
damon_lru_sort_apply_parameters()allocates a new DAMON context, stages user-specified DAMON parameters on it, and commits to running DAMON context at once, usingdamon_commit_ctx(). The code is, however, directly updating the monitoring attributes of the running context. This doesn't cause a real user problem but apparently this is an unintentional mistake that can cause code review confusions and future real problems. Fix the wrong use of the parameter context.
Quoted 4 lines
Hi SJ,
Thank you for the patch! I am a little bit confused by the behavior in
damon_lru_sort_apply_parameters. I was hoping that you could help me understand : -)
Thank you for sharing this Joshua!
Quoted 9 lines
In particular, I think that this patch fixes two possible user visible errors.
My understanding is that we want to make changes to the
param_ctxfirst, validate the changes, and commit these changes to the global ctx struct at the end. In the middle in the errors, we can abort the operation without committing, and ctx will remain unchanged.So to me, it does seem like the current code could lead to some visible effects from the user's perspective (error-handling case).
damon_set_attrs() has its own parameters validation. If the validation fails, it returns an error. damon_commit_ctx()'s internal validation for damon_attrs parameters also depend on the validsation of damon_set_attrs(). If the given parameter is invalid, damon_set_attrs() will return an error without committing the change, so there should be no user-visible behavioral difference.
Quoted 15 lines
Also, I am a bit confused by how the commit is currently called. We have err =
damon_commit_ctx(ctx, param_ctx), where the first argument is the destination and the second argument is the source. There is a bit of a mismatch because in the current code we have the following:+------------------------------------------------+ | ctx param_ctx | +------------------------------------------------+ | New &damon_lru_sort_mon_attrs | | New scheme | | attrs overwritten to NULL <-- | | scheme rewritten to new scheme <-- | +------------------------------------------------+
Quoted 8 lines
So in particular, the global ctx will never have the correct attrs pre-patch, since it will always be rewritten by
param_ctx, which never had its attrs initialized.I hope this makes sense : -) All of this is just to say that this patch does more than just improve review confusions -- I think there at least two errors that this fixes for the user. So perhaps a more descriptive commit will be helpful in the future, since we are also adding a fixes tag?
Makes sense, thank you for finding this Joshua! I will send v2 of this patch with updated commit message!
Quoted 3 lines
Thank you again for the patch, SJ! Feel free to add:
Reviewed-by Joshua Hahn <[email protected]>
Thank you!
Thanks,
SJ
[...]
SeongJae Park
maintainerRe: [PATCH 3/6] mm/damon/lru_sort: use param_ctx correctly
Quoted 11 lines · On Mon, 15 Sep 2025 11:43:06 -0700 SeongJae Park <[email protected]> wrote:
Quoted 9 lines · On Mon, 15 Sep 2025 08:05:47 -0700 Joshua Hahn <[email protected]> wrote:
Quoted 7 lines · On Sun, 14 Sep 2025 18:58:04 -0700 SeongJae Park <[email protected]> wrote:
damon_lru_sort_apply_parameters()allocates a new DAMON context, stages user-specified DAMON parameters on it, and commits to running DAMON context at once, usingdamon_commit_ctx(). The code is, however, directly updating the monitoring attributes of the running context. This doesn't cause a real user problem but apparently this is an unintentional mistake that can cause code review confusions and future real problems. Fix the wrong use of the parameter context.
[...]
Quoted 3 lines
Quoted 3 lines
So in particular, the global ctx will never have the correct attrs pre-patch, since it will always be rewritten by
param_ctx, which never had its attrs initialized.
[...]
And it measn the monitoring attributes prameters of DAMON_LRU_SORT are not working at all. I think this deserves to be a hotfix. I will send v2 of this separately, cc-ing stable@.
Thanks,
SJ
[...]
SeongJae Park
maintainerPATCH 4/6 Docs/mm/damon/maintainer-profile: update community meetup for reservation requirements
In reply to SeongJae ParkDAMON community meetup was having two different kinds of meetups:
reservation required ones and unrequired ones. Now the reservation unrequested one is gone, but the documentation on the maintainer-profile is not updated. Update.
--- Documentation/mm/damon/maintainer-profile.rst | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-)
Documentation/mm/damon/maintainer-profile.rst +6 -11
@@ -89,18 +89,13 @@ the maintainer. Community meetup ---------------- -DAMON community is maintaining two bi-weekly meetup series for community -members who prefer synchronous conversations over mails. +DAMON community has a bi-weekly meetup series for members who prefer +synchronous conversations over mails. It is for discussions on specific topics +between a group of members including the maintainer. The maintainer shares the +available time slots, and attendees should reserve one of those at least 24 +hours before the time slot, by reaching out to the maintainer. -The first one is for any discussion between every community member. No -reservation is needed. - -The seconds one is for discussions on specific topics between restricted -members including the maintainer. The maintainer shares the available time -slots, and attendees should reserve one of those at least 24 hours before the -time slot, by reaching out to the maintainer. - -Schedules and available reservation time slots are available at the Google `doc +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>`_
Signature · 1 line
2.39.5
Re: [PATCH 4/6] Docs/mm/damon/maintainer-profile: update community meetup for reservation requirements
Quoted 4 lines · On Sun, 14 Sep 2025 18:58:05 -0700 SeongJae Park <[email protected]> wrote:
DAMON community meetup was having two different kinds of meetups:
reservation required ones and unrequired ones. Now the reservation unrequested one is gone, but the documentation on the maintainer-profile is not updated. Update.
LGTM!
Quoted 36 lines
Signed-off-by SeongJae Park <[email protected]>--- Documentation/mm/damon/maintainer-profile.rst | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-)Documentation/mm/damon/maintainer-profile.rst +6
-11@@ -89,18 +89,13 @@ the maintainer. Community meetup ---------------- -DAMON community is maintaining two bi-weekly meetup series for community -members who prefer synchronous conversations over mails. +DAMON community has a bi-weekly meetup series for members who prefer +synchronous conversations over mails. It is for discussions on specific topics +between a group of members including the maintainer. The maintainer shares the +available time slots, and attendees should reserve one of those at least 24 +hours before the time slot, by reaching out to the maintainer. -The first one is for any discussion between every community member. No -reservation is needed. - -The seconds one is for discussions on specific topics between restricted -members including the maintainer. The maintainer shares the available time -slots, and attendees should reserve one of those at least 24 hours before the -time slot, by reaching out to the maintainer. - -Schedules and available reservation time slots are available at the Google `doc +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>`_Signature · 1 line
2.39.5
Sent using hkml (https://github.com/sjp38/hackermail)
SeongJae Park
maintainerRe: [PATCH 4/6] Docs/mm/damon/maintainer-profile: update community meetup for reservation requirements
Quoted 9 lines · On Mon, 15 Sep 2025 08:07:01 -0700 Joshua Hahn <[email protected]> wrote:
Quoted 4 lines · On Sun, 14 Sep 2025 18:58:05 -0700 SeongJae Park <[email protected]> wrote:
DAMON community meetup was having two different kinds of meetups:
reservation required ones and unrequired ones. Now the reservation unrequested one is gone, but the documentation on the maintainer-profile is not updated. Update.LGTM!
Reviewed-by Joshua Hahn <[email protected]>
Thank you!
Thanks,
SJ
[...]
SeongJae Park
maintainerPATCH 5/6 Docs/admin-guide/mm/damon/start: add --target_pid to DAMOS example command
In reply to SeongJae ParkThe example command doesn't work [1] on the latest DAMON user-space tool, since --damos_action option is updated to receive multiple arguments, and hence cannot know if the final argument is for deductible monitoring target or an argument for --damos_action option. Add --target_pid option to let damo understand it is for target pid.
[1] https://github.com/damonitor/damo/pull/32
--- Documentation/admin-guide/mm/damon/start.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/admin-guide/mm/damon/start.rst +1 -1
@@ -175,4 +175,4 @@ Below command makes every memory region of size >=4K that has not accessed for $ sudo damo start --damos_access_rate 0 0 --damos_sz_region 4K max \ --damos_age 60s max --damos_action pageout \ - <pid of your workload> + --target_pid <pid of your workload>
Signature · 1 line
2.39.5
SeongJae Park
maintainerPATCH 6/6 MAINTAINERS: rename DAMON section
In reply to SeongJae ParkDAMON section name is 'DATA ACCESS MONITOR', which implies it is only for data access monitoring. But DAMON is now evolved for not only access monitoring but also access-aware system operations (DAMOS). Rename the section to simply DAMON. It might make it difficult to understand what it does at a glance, but at least not spreading more confusion. Readers can further refer to the documentation to better understand what really DAMON does.
--- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
MAINTAINERS +1 -1
@@ -6738,7 +6738,7 @@ S: Maintained W: https://docs.dasharo.com/ F: drivers/platform/x86/dasharo-acpi.c -DATA ACCESS MONITOR +DAMON M: SeongJae Park <[email protected]> L: [email protected] L: [email protected]
Signature · 1 line
2.39.5
Quoted 12 lines · On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <[email protected]> wrote:
Misc fixes and improvements for DAMON that are not critical and therefore aims to be merged into Linux 6.18-rc1.
The first patch improves DAMON's age counting for
nr_accesseszero to/from non-zero changes.The second patch fixes an initial DAMOS apply interval delay issue that is not realistic but still could happen on an odd setup.
The third patch fixes wrongly written code that doesn't cause any real problem but could make code review confusing.
Quoted 6 lines
The fourth and the fifth patches update DAMON community meetup description and DAMON user-space tool example command for DAMOS usage, respectively.
Finally, the sixth patch updates
MAINTAINERSsection name for DAMON to just DAMON.
Hi SJ,
I was unable to find this sixth patch on the mailing list. Maybe it got dropped somewhere? : -)
Quoted 25 lines
Changes from RFC
(https://lore.kernel.org/[email protected])
- The RFC was only for the first patch
- Rebase and wordsmith the first patch
- Add a few misc fixes and improvements for 6.18 to the seriesSeongJae Park (6):
mm/damon/core: reset age ifnr_accesseschanges between non-zero and
zero
mm/damon/core: set effective quota on first charge windowmm/damon/lru_sort: useparam_ctxcorrectly Docs/mm/damon/maintainer-profile: update community meetup for
reservation requirements
Docs/admin-guide/mm/damon/start: add --target_pid to DAMOS example
command
MAINTAINERS: rename DAMON sectionDocumentation/admin-guide/mm/damon/start.rst | 2 +- Documentation/mm/damon/maintainer-profile.rst | 17 ++++++----------- MAINTAINERS | 2 +- mm/damon/core.c | 7 ++++++- mm/damon/lru_sort.c | 2 +- 5 files changed, 15 insertions(+), 15 deletions(-)
Quoted 3 lines
base-commit:
d245e17d619ea0336d50b0a6c914f5701d1b0e53Signature · 1 line
2.39.5
Sent using hkml (https://github.com/sjp38/hackermail)
Quoted 19 lines · Joshua Hahn
Quoted 16 lines · On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <[email protected]> wrote:
Misc fixes and improvements for DAMON that are not critical and therefore aims to be merged into Linux 6.18-rc1.
The first patch improves DAMON's age counting for
nr_accesseszero to/from non-zero changes.The second patch fixes an initial DAMOS apply interval delay issue that is not realistic but still could happen on an odd setup.
The third patch fixes wrongly written code that doesn't cause any real problem but could make code review confusing.
The fourth and the fifth patches update DAMON community meetup description and DAMON user-space tool example command for DAMOS usage, respectively.
Quoted 7 lines
Quoted 2 lines
Finally, the sixth patch updates
MAINTAINERSsection name for DAMON to just DAMON.Hi SJ,
I was unable to find this sixth patch on the mailing list. Maybe it got dropped somewhere? : -)
I'm seeing it show up for me, this is the link I'm looking at
https://lore.kernel.org/all/[email protected]/
Quoted 31 lines
Quoted 26 lines
Changes from RFC
(https://lore.kernel.org/[email protected])
- The RFC was only for the first patch
- Rebase and wordsmith the first patch
- Add a few misc fixes and improvements for 6.18 to the seriesSeongJae Park (6):
mm/damon/core: reset age ifnr_accesseschanges between non-zero and
zero
mm/damon/core: set effective quota on first charge windowmm/damon/lru_sort: useparam_ctxcorrectly Docs/mm/damon/maintainer-profile: update community meetup for
reservation requirements
Docs/admin-guide/mm/damon/start: add --target_pid to DAMOS example
command
MAINTAINERS: rename DAMON sectionDocumentation/admin-guide/mm/damon/start.rst | 2 +- Documentation/mm/damon/maintainer-profile.rst | 17 ++++++----------- MAINTAINERS | 2 +- mm/damon/core.c | 7 ++++++- mm/damon/lru_sort.c | 2 +- 5 files changed, 15 insertions(+), 15 deletions(-)Quoted 3 lines
base-commit:
d245e17d619ea0336d50b0a6c914f5701d1b0e53--
2.39.5Sent using hkml (https://github.com/sjp38/hackermail)
Quoted 23 lines · On Mon, 15 Sep 2025 08:25:40 -0700 Joanne Koong <[email protected]> wrote:
Quoted 22 lines · Joshua Hahn
Quoted 18 lines · On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <[email protected]> wrote:
Misc fixes and improvements for DAMON that are not critical and therefore aims to be merged into Linux 6.18-rc1.
The first patch improves DAMON's age counting for
nr_accesseszero to/from non-zero changes.The second patch fixes an initial DAMOS apply interval delay issue that is not realistic but still could happen on an odd setup.
The third patch fixes wrongly written code that doesn't cause any real problem but could make code review confusing.
The fourth and the fifth patches update DAMON community meetup description and DAMON user-space tool example command for DAMOS usage, respectively.
Finally, the sixth patch updates
MAINTAINERSsection name for DAMON to just DAMON.
Quoted 7 lines
Quoted 4 lines
Hi SJ,
I was unable to find this sixth patch on the mailing list. Maybe it got dropped somewhere? : -)
I'm seeing it show up for me, this is the link I'm looking at
https://lore.kernel.org/all/[email protected]/
Hi Joanne,
Thanks, it seems like linux-mm wasn't CCed on the 6th patch. I should have checked in /all! Have a great day!
Joshua
Sent using hkml (https://github.com/sjp38/hackermail)
SeongJae Park
maintainerQuoted 5 lines · On Mon, 15 Sep 2025 08:28:18 -0700 Joshua Hahn <[email protected]> wrote:
Quoted 3 lines · On Mon, 15 Sep 2025 08:25:40 -0700 Joanne Koong <[email protected]> wrote:
Quoted 2 lines · Joshua Hahn
On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <[email protected]> wrote:
[...]
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
Finally, the sixth patch updates
MAINTAINERSsection name for DAMON to just DAMON.Hi SJ,
I was unable to find this sixth patch on the mailing list. Maybe it got dropped somewhere? : -)
Quoted 6 lines
Quoted 2 lines
I'm seeing it show up for me, this is the link I'm looking at
https://lore.kernel.org/all/[email protected]/Hi Joanne,
Thanks, it seems like linux-mm wasn't CCed on the 6th patch.
Thanks for sharing these findings, Joshua and Joanne! I was using 'get_maintainer.pl' via 'hkml patch format' to fill in the recipients field, and it warned me with recipients review step, but I missed this. I will ensure linux-mm@ is Cc-ed from the next version.
Quoted 2 lines
I should have
checked in /all!
FYI, if you use hkml, you can list all mails of a thread of a mail using 't' key on list screen, or 'm' key on the list screen -> '2: list complete thread' item on the menu screen, instead of '/all'. It should work for cases like this.
Quoted 1 line
Have a great day!
You too!
Thanks,
SJ
[...]