Re: [RFC v2] mm/damon: add synchronous validation for commit_inputs

[SeongJae Park <sj@kernel.org>]

On Sun, 22 Mar 2026 14:06:30 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> Hi SeongJae,
> 
> I tried implementing the synchronous commit using damon_call() as
> suggested, similar to how damon_sysfs_commit_input() works. This
> successfully returns errors to userspace immediately instead of failing
> silently.

Nice.

> 
> However, I observed a side effect during testing:
> Since damon_call() waits for the kdamond thread to process the request,
> the latency of writing to 'commit_inputs' depends on the kdamond's
> wake-up interval (controlled by damos_watermarks.interval).
> 
> In my test with DAMON_LRU_SORT:
> - With '.interval=5s', the write latency can be up to ~5 seconds.
> - When I temporarily increase '.interval=50s' for testing, the latency
>   increased proportionally.
> 
> I understand this is expected behavior for synchronous communication
> with a sleeping kernel thread. However, since 'commit_inputs' is a
> control interface rather than a hot path, I wanted to comfirm:
> 
> Is this level of latency acceptable for the 'commit_inputs' parameter?
> Or should we consider waking up the kdamond thread immediately upon
> receiving a damon_call() request to reduce the worst-case latency?

I believe this level of latency is acceptable.  The special-purpose DAMON
modules are designed for long term use with minimum control.  So I expect
commit_inputs to be used only occasionally in real use case.

Of course, making it faster would be nice, as long as the required change is
very simple.  I have no good ideea about making it really simple, though.
Nonetheless, I think it is not too late to do that after someone starts
complaining, or we find a really good idea.

> 
> For reference, DAMON_SYSFS seems to have similar latency
> charactheristics when using damon_call().

You are right.  And we got no complain about it so far, so I believe that
latency for DAMON_RECLAIM and DAMON_LRU_SORT should be fine.

> 
> Thank you for you high-level comments and the suggestion! :>

My pleasure :)


Thanks,
SJ

[...]