damon_call(9)
π damon_call(9) β bestie edition
okay so this is a page from the Kernel API Manual, and honestly? it's kind of a slay. it's damon_call(9), and it's about politely asking a kernel worker thread to run your function for you. let's get into it π«Ά
β¨ NAME β¨
damon_call β invoke a given function on the DAMON worker thread (kdamond). that's the whole vibe. it's giving "hey bestie, can you run this for me" but in kernel land π
πΈ SYNOPSIS πΈ
int damon_call (struct damon_ctx *ctx , struct damon_call_control
*control );
two args, one int coming back. simple. iconic. no notes β¨
π ARGUMENTS π
ctxβ the DAMON context you're calling the function for. like, which context. this matters, bestie, don't skip it.controlβ the control variable of the call request. it's the little envelope holding your function, your data, and all the settings. literally the main character of this whole operation π
π¦ DESCRIPTION π¦
so here's the tea β you're asking the DAMON worker thread (that's kdamond, for short) belonging to ctx to call a function. which function? whichever one you passed via damon_call_control->fn of control. and the argument it gets? that comes from damon_call_control->data of control. two fields, one request, so clean β¨
now here's where it gets interesting π β if damon_call_control->repeat of control is unset, then this function waits until kdamond is done handling the request before it returns. like it's standing outside the door waiting for the answer. otherwise (if repeat is set), it returns as soon as the request is made β no waiting, bye π
and when does kdamond actually run your function? in the main loop, just after a sampling of the iteration is finished. the timing is chef's kiss π which means your function can safely access the internal data of the struct damon_ctx without additional synchronization. no locks, no stress, no crying over race conditions. ate π
the return value of your function? it gets saved in damon_call_control->return_code. tracked. documented. immortalized β¨
β οΈ okay this part is important, bestie, like actually. this function should be called only afterdamon_startwith thectxhas succeeded. otherwise, this function could fall into an indefinite wait π and nobody wants that. it's giving "stuck in the group chat waiting for a reply that's never coming."
π also: when this function fails, the ctx is guaranteed to be stopped. that's not a drill, that's a guarantee.
π RETURN π
0on success π- negative error code otherwise π
that's it. that's the whole return section. short and honest fr fr.
π SEE ALSO π
go read these next, bestie, they're all in the kernel file ./mm/damon/core.c:
damon_is_registered_ops(9), damon_register_ops(9), damon_select_ops(9), damon_nr_accesses_mvsum(9), damon_probe_hits_wsum(9), damos_filter_for_ops(9), damon_set_attrs(9), damon_set_schemes(9), damos_commit_quota_goals(9), damos_filters_default_reject(9), damon_commit_ctx(9), damon_nr_running_ctxs(9), damon_start(9), damon_stop(9), damon_is_running(9), damon_kdamond_pid(9), damos_walk(9), damon_set_region_system_rams_default(9), damon_update_region_access_rate(9), damon_initialized(9)
π and that's the page!! this one came out of ./mm/damon, dated October 2026, in the Kernel API Manual β mwah, sending you a forehead kiss, now go call a function on a worker thread responsibly π§β¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms