Re: [RFC PATCH 0/4] rust: damon: a first small step, plus a Rust prcl sample

[SJ Park <sj@kernel.org>]

Hi Enze,

On Sun, 27 Sep 2026 15:28:08 +0800 Enze Li <lienze@kylinos.cn> wrote:

> Hi SJ, hi all,
> 
> Almost a year ago, right after a memory-leak fix discussion on this list, I
> asked whether introducing Rust for some DAMON modules could be worth
> exploring as a proactive measure.  SJ's answer was positive: he was open to
> Rust adoption in DAMON, both in kernel and user space, and even mentioned
> he had been wanting to write a Rust sample DAMON module himself since LPC,
> but had not found the time yet [1].
> 
> So, here is my attempt at making that start happen.  This RFC is
> intentionally small: it adds just enough Rust support for DAMON to port the
> proactive reclamation sample (prcl.c), and nothing more.

Thank you for this patch series!  Yes, I'm interested in Rust, though I didn't
have sufficient time to dig in yet.  I'm planning to attend Rust for Linux
training day [1] on next Sunday.

TLDR: I feel like we might need to wait or focus on module parameter support in
Rust, ongoing DAMON extension works before adopting Rust in DAMON.  Also, I'd
suggest starting with wsse, which is simpler.

> 
> The series has four patches:
> 
>   1. Generate Rust bindings for include/linux/damon.h.
>   2. Add thin safe wrappers in a new rust::kernel::damon module: contexts,
>      targets, access patterns, quotas, watermarks, schemes, plus
>      start/stop.  Everything FFI-related is confined to the wrappers, with
>      the usual SAFETY comments; error codes are returned as kernel::Result.
>   3. Add samples/damon/rust_prcl.rs, a Rust port of prcl.c.  It watches the
>      virtual address space of a target process and pages out cold regions
>      with the DAMOS_PAGEOUT action, same access-pattern filter as the C
>      version.

I'd suggest starting from porting wsse, because it is simplest.  By scoping
down to it, you could drop the wrappers for DAMOS.

>   4. Add a MAINTAINERS entry for the two new files.
> 
> Two differences from the C sample are worth noting.
> 
> First, the control interface.  The C prcl sample is driven through
> runtime-writable module parameters (target_pid and enabled, the latter via
> module_param_cb), neither of which Rust can express yet -- its module
> parameters are load-time only and do not show up under /sys/module/, and
> there is no general sysfs abstraction in mainline or the RfL rust-next
> tree.  The debugfs abstraction, however, already provides the safe
> read/write wrappers we need, so the Rust sample exposes the same two knobs
> under /sys/kernel/debug/rust_prcl/.  This is a temporary detour, not a
> design preference: the sample will be switched over to match the C
> interface once Rust supports sysfs-backed module parameters.

Do we have a timeline for module parameters support in Rust?  I'd prefer to
avoid use of debugfs and directly start with sysfs.

> 
> Second, the functional scope.  The C sample also repeatedly reports the
> estimated working set size via a repeating damon_call() callback.  This
> initial Rust version covers only the core monitoring/reclamation path
> (context, target, PAGEOUT scheme, start/stop); wss reporting needs safe
> wrappers for damon_call() and region iteration, which will come in a
> follow-up series that also makes the Rust sample's output match the C
> one's.

As I abovely mentioned, I'd prefer porting wsse first, and later extend to
DAMOS-based samples like prcl and mtier.

> 
> A quick word on the longer-term plan, so the design discussion here can
> happen with the destination in mind:
> 
>   - Over roughly the next year, I would like to port the other two DAMON
>     samples (wsse and mtier) to Rust as well, and let the DAMON Rust
>     compatibility layer grow together with them, wrapping only what real
>     in-tree users need.
>   - Once that layer has matured, I would be happy to try Rust for the
>     production modules - damon/reclaim, damon/lru_sort and damon/stat.
>     That is a much bigger step, of course, and it only happens if SJ is
>     comfortable with it.  Consider it a willingness statement, not a
>     promise.

I think that's a good plan.  However, I'd like to call out we will also need to
make each step with good and sufficient discussions.  That is, for each step,
we will discuss if the previous step change was helpful and therefore make
sense to proceed to the next step.  If the conclusion is oppostie, we could
even revert the previous changes.  It would be great if we could make it driven
by data.

> 
> Regarding the MAINTAINERS patch: I listed myself for the new files, but did
> not add SJ as a reviewer yet, since he mentioned limited bandwidth for Rust
> work in that earlier discussion.  The existing DAMON entry already covers
> samples/damon/, so the sample reaches him regardless; adding him to the
> RUST [DAMON] entry would only additionally route future changes to
> rust/kernel/damon.rs his way.  Happy to add the R: line if he wants it, or
> leave it out if he prefers.

I think I should at least review the patches.  Also I feel I am responsible to
the maintenance of the code.

We are extending DAMON to work for not only data access but general data
attributes.  I'm also planning to refactor DAMON API quite a lot in near
future.  Some interfaces will be added and removed.  DAMON API callers
including sample modules would also need to be changed a lot.  If we make the
Rust sample module with the current API, we may need to make changes not only
in C but also Rust parts.  I concern if it can introduce more breakages that
require unnecessarily long time to fix.  Among all, my lack of Rust
understanding is a big concern.

I understand this patch series is a kind of experiment rather than for a real
use case that has a hard deadline.  If I'm not incorrect, I feel like this
might not be the best time to start the experiment.  Could we wait until
fundamental parts including module parameters support in Rust and ongoing DAMON
reconstruction, or my learning of Rust are done and stabilized?

I may missing many things.  I might simply rejecting this great opportunity
only due to my laziness.  Please push back if you find so.

[1] https://lore.kernel.org/all/rust-at-lpc2026@google.com/


Thanks,
SJ

[...]