Re: [RFC PATCH v3 04/37] mm/damon/core: implement damon_report_page_fault()

[JaeJoon Jung <rgbi3307@gmail.com>]

On Sat, 13 Dec 2025 at 09:56, SeongJae Park <sj@kernel.org> wrote:
>
> On Sat, 13 Dec 2025 09:31:22 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
>
> > On Sat, 13 Dec 2025 at 07:47, SeongJae Park <sj@kernel.org> wrote:
> > >
> > > On Fri, 12 Dec 2025 21:46:03 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
> > >
> > > > On Mon, 8 Dec 2025 at 15:33, SeongJae Park <sj@kernel.org> wrote:
> > > > >
> > > > > Implement a DAMON core API for reporting page fault events to DAMON.  It
> > > > > is a wrapper of damon_report_access().
> > > > >
> > > > > This is a temporal hack.  In future versions that will have no RFC tag,
> > > > > only damon_report_access() may be used.
> > > >
> > > > It's a minor, but git am throws an error when applying the [RFC PATCH v3 04/37]
> > > > patch file.
> > >
> > > Interesting.  I can do 'git am' this patch without error on mm-new branch.  Are
> > > you using something other than mm-new as your baseline?
> > >
> > > > I am testing it by modifying it as follows.
> > > > damon_report_access() is
> > > > called by damon_report_page_fault(), so they depend on each other.
> > > >
> > > > #ifdef CONFIG_MMU
> > > > void damon_report_access(struct damon_access_report *report);
> > > > void damon_report_page_fault(struct vm_fault *vmf, bool huge_pmd);
> > > > #else
> > > > static inline void damon_report_access(struct damon_access_report *report)
> > > > {
> > > > }
> > > > static inline void damon_report_page_fault(struct vm_fault *vmf, bool huge_pmd)
> > > > {
> > > > }
> > > > #endif
> > >
> > > Seems this is not for fixing a 'git am' error but build error...?  Can you
> > > share what error exactly you are seeing?
> >
> > You have been deploying RFC PATCH v1, v2, and v3 starting from 2025-06-29.
> > I am currently working with the latest version v6.18.1 (as of 2025-12-13).
> >
> > $ head Makefile
> > # SPDX-License-Identifier: GPL-2.0
> > VERSION = 6
> > PATCHLEVEL = 18
> > SUBLEVEL = 1
> > EXTRAVERSION =
> > NAME = Baby Opossum Posse
> >
> > When applying RFC PATCH v1, v2, v3 with the above version, errors occur
> > in several places in 'git am' as follows.
> >
> > -------- [RFC PATCH v1] -------------------------------------------------
> >
> > $ git am '[RFC PATCH 1/6]'
> > Applying: mm/damon/core: introduce damon_report_access()
> >
> > $ git am '[RFC PATCH 2/6]'
> > Applying: mm/damon/core: add eliglble_report() ops callback
> >
> > $ git am '[RFC PATCH 3/6]'
> > Applying: mm/damon/core: check received access reports
> >
> > $ git am '[RFC PATCH 4/6]'
> > Applying: mm/damon/vaddr: impleement eligible_report() callback
> > error: patch failed: mm/damon/vaddr.c:610
> > error: mm/damon/vaddr.c: patch does not apply
> > Patch failed at 0001 mm/damon/vaddr: impleement eligible_report() callback
> > hint: Use 'git am --show-current-patch=diff' to see the failed patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
> [...]
>
> Thank you for sharing these!  We are working on moving baseline, specifically
> mm-new in most cases.  And we keep under-development patches on damon/next
> tree.  Please refer to the document [1] for more details.
>
> And a later version of the patch series is for replacing the old version.  If
> you have no special reason to apply the old versions of the patches, I'd
> suggest to use only the latest version.  And if you have no special reasons to
> use only 6.18.1, I'd recommend to just play with the commits on damon/next
> tree that was used to generate the patch files.
>
> Nonetheless, if you have a strong reason to do work on only 6.18.1, please feel
> free to ask help if needed.
>
> > If I build the kernel with the above status, I get compilation errors
> > as follows.
> >
> > /home/arm64/projects/kernel/linux-stable/mm/damon/sysfs.c:758:25:
> > error: ‘DAMON_FILTER_TYPE_WRITE’ undeclared here (not in a function);
> > did you mean ‘DAMOS_FILTER_TYPE_TARGET’?
> >   758 |                 .type = DAMON_FILTER_TYPE_WRITE,
> >       |                         ^~~~~~~~~~~~~~~~~~~~~~~
> >       |                         DAMOS_FILTER_TYPE_TARGET
> [...]
>
> Makes sense.  Again, I'd recommend using mm-new as your baseline or play with
> the commits on damon/next, but if you need help, please feel free to reach out
> :)

Thank you for your detailed and kind reply.
I am glad to refer to damon/next and mm-new in the document [1] you provided.
I will continue to share the analysis with you.

>
> [1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
> [2]
>
> Thanks,
> SJ
>
> [...]