[PATCH 0/6] mm/damon: misc fixups and improvements for 6.18

[PATCH 0/6] mm/damon: misc fixups and improvements for 6.18

[SeongJae Park]

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/20250909034353.7064-1-sj@kernel.org)
- 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
-- 
2.39.5

[PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero

[SeongJae Park]

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.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index be5942435d78..996647caca02 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -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++;
 
-- 
2.39.5

Re: [PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero

[Joshua Hahn]

On Sun, 14 Sep 2025 18:58:02 -0700 SeongJae Park <sj@kernel.org> wrote:

> 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.

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!

Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

> Signed-off-by: SeongJae Park <sj@kernel.org>
> ---
>  mm/damon/core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index be5942435d78..996647caca02 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -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++;
>  
> -- 
> 2.39.5

Sent using hkml (https://github.com/sjp38/hackermail)

Re: [PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero

[SeongJae Park]

On Mon, 15 Sep 2025 07:51:57 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> On Sun, 14 Sep 2025 18:58:02 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> > 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.
> 
> 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?

Thank you for the idea, this makes sense!

> 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.

> 
> 
> Anyways, the rest of it looks good to me, please feel free to add my review!
> 
> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Thank you!

> 
> > Signed-off-by: SeongJae Park <sj@kernel.org>
> > ---
> >  mm/damon/core.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index be5942435d78..996647caca02 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -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++;
> >  
> > -- 
> > 2.39.5
> 
> Sent using hkml (https://github.com/sjp38/hackermail)


Thanks,
SJ

[...]

Re: [PATCH 1/6] mm/damon/core: reset age if nr_accesses changes between non-zero and zero

[Andrew Morton]

On Mon, 15 Sep 2025 11:26:51 -0700 SeongJae Park <sj@kernel.org> wrote:

> > 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!
> 
> > 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.

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.

[PATCH 2/6] mm/damon/core: set effective quota on first charge window

[SeongJae Park]

The 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.

Fixes: 1cd243030059 ("mm/damon/schemes: implement time quota") # 5.16.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 996647caca02..84de1cea5440 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -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 +
-- 
2.39.5

[PATCH 3/6] mm/damon/lru_sort: use param_ctx correctly

[SeongJae Park]

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, 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.

Fixes: a30969436428 ("mm/damon/lru_sort: use damon_commit_ctx()")
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/lru_sort.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
index 14d31009c09e..ab6173a646bd 100644
--- a/mm/damon/lru_sort.c
+++ b/mm/damon/lru_sort.c
@@ -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;
 
-- 
2.39.5

Re: [PATCH 3/6] mm/damon/lru_sort: use param_ctx correctly

[Joshua Hahn]

On Sun, 14 Sep 2025 18:58:04 -0700 SeongJae Park <sj@kernel.org> 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, 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.

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:
Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Have a great day!
Joshua

> Fixes: a30969436428 ("mm/damon/lru_sort: use damon_commit_ctx()")
> Signed-off-by: SeongJae Park <sj@kernel.org>
> ---
>  mm/damon/lru_sort.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> index 14d31009c09e..ab6173a646bd 100644
> --- a/mm/damon/lru_sort.c
> +++ b/mm/damon/lru_sort.c
> @@ -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;
>  
> -- 
> 2.39.5

Sent using hkml (https://github.com/sjp38/hackermail)

Re: [PATCH 3/6] mm/damon/lru_sort: use param_ctx correctly

[SeongJae Park]

On Mon, 15 Sep 2025 08:05:47 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> On Sun, 14 Sep 2025 18:58:04 -0700 SeongJae Park <sj@kernel.org> 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, 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.
> 
> 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!

> 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).

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.

> 
> 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?

Makes sense, thank you for finding this Joshua!  I will send v2 of this patch
with updated commit message!

> 
> Thank you again for the patch, SJ! Feel free to add:
> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Thank you!


Thanks,
SJ

[...]

Re: [PATCH 3/6] mm/damon/lru_sort: use param_ctx correctly

[SeongJae Park]

On Mon, 15 Sep 2025 11:43:06 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Mon, 15 Sep 2025 08:05:47 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
> 
> > On Sun, 14 Sep 2025 18:58:04 -0700 SeongJae Park <sj@kernel.org> 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, 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.
[...]
> > 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

[...]

[PATCH 4/6] Docs/mm/damon/maintainer-profile: update community meetup for reservation requirements

[SeongJae Park]

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.

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 Documentation/mm/damon/maintainer-profile.rst | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst
index 5cd07905a193..58a3fb3c5762 100644
--- a/Documentation/mm/damon/maintainer-profile.rst
+++ b/Documentation/mm/damon/maintainer-profile.rst
@@ -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>`_
-- 
2.39.5

Re: [PATCH 4/6] Docs/mm/damon/maintainer-profile: update community meetup for reservation requirements

[Joshua Hahn]

On Sun, 14 Sep 2025 18:58:05 -0700 SeongJae Park <sj@kernel.org> 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 <joshua.hahnjy@gmail.com>

> Signed-off-by: SeongJae Park <sj@kernel.org>
> ---
>  Documentation/mm/damon/maintainer-profile.rst | 17 ++++++-----------
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst
> index 5cd07905a193..58a3fb3c5762 100644
> --- a/Documentation/mm/damon/maintainer-profile.rst
> +++ b/Documentation/mm/damon/maintainer-profile.rst
> @@ -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>`_
> -- 
> 2.39.5

Sent using hkml (https://github.com/sjp38/hackermail)

Re: [PATCH 4/6] Docs/mm/damon/maintainer-profile: update community meetup for reservation requirements

[SeongJae Park]

On Mon, 15 Sep 2025 08:07:01 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> On Sun, 14 Sep 2025 18:58:05 -0700 SeongJae Park <sj@kernel.org> 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 <joshua.hahnjy@gmail.com>

Thank you!


Thanks,
SJ

[...]

[PATCH 5/6] Docs/admin-guide/mm/damon/start: add --target_pid to DAMOS example command

[SeongJae Park]

The 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

Signed-off-by: SeongJae Park <sj@kernel.org>
---
 Documentation/admin-guide/mm/damon/start.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst
index ede14b679d02..ec8c34b2d32f 100644
--- a/Documentation/admin-guide/mm/damon/start.rst
+++ b/Documentation/admin-guide/mm/damon/start.rst
@@ -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>
-- 
2.39.5

Re: [PATCH 0/6] mm/damon: misc fixups and improvements for 6.18

[Joshua Hahn]

On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <sj@kernel.org> 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_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.

Hi SJ,

I was unable to find this sixth patch on the mailing list. Maybe it got dropped
somewhere? : -) 

> Changes from RFC
> (https://lore.kernel.org/20250909034353.7064-1-sj@kernel.org)
> - 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
> -- 
> 2.39.5

Sent using hkml (https://github.com/sjp38/hackermail)

Re: [PATCH 0/6] mm/damon: misc fixups and improvements for 6.18

[Joanne Koong]

On Mon, Sep 15, 2025 at 8:08 AM Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
>
> On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <sj@kernel.org> 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_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.
>
> 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/20250915015807.101505-7-sj@kernel.org/

>
> > Changes from RFC
> > (https://lore.kernel.org/20250909034353.7064-1-sj@kernel.org)
> > - 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
> > --
> > 2.39.5
>
> Sent using hkml (https://github.com/sjp38/hackermail)

Re: [PATCH 0/6] mm/damon: misc fixups and improvements for 6.18

[Joshua Hahn]

On Mon, 15 Sep 2025 08:25:40 -0700 Joanne Koong <joannelkoong@gmail.com> wrote:

> On Mon, Sep 15, 2025 at 8:08 AM Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
> >
> > On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <sj@kernel.org> 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_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.
> >
> > 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/20250915015807.101505-7-sj@kernel.org/

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)

Re: [PATCH 0/6] mm/damon: misc fixups and improvements for 6.18

[SeongJae Park]

On Mon, 15 Sep 2025 08:28:18 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> On Mon, 15 Sep 2025 08:25:40 -0700 Joanne Koong <joannelkoong@gmail.com> wrote:
> 
> > On Mon, Sep 15, 2025 at 8:08 AM Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
> > >
> > > On Sun, 14 Sep 2025 18:58:01 -0700 SeongJae Park <sj@kernel.org> wrote:
[...]
> > > > Finally, the sixth patch updates MAINTAINERS section 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/20250915015807.101505-7-sj@kernel.org/
> 
> 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.

> 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.

> Have a great day!

You too!


Thanks,
SJ

[...]