STRUCT DAMON_OPERATIONS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ‘‘ struct damon_operations(9) β€” like, the whole kernel API manual vibe, but make it make sense

okay bestie, welcome to the Kernel API Manual page for struct damon_operations(9) β€” this is the plug-in system for DAMON, and honestly? it ate. let's get into it πŸ’…


✨ NAME ✨

struct damon_operations β€” monitoring operations for given use cases. that's it, that's the vibe check πŸ¦‹


🌸 SYNOPSIS 🌸

struct damon_operations {
    enum damon_ops_id id;
    void (*init)(struct damon_ctx *context);
    void (*update)(struct damon_ctx *context);
    void (*prepare_access_checks)(struct damon_ctx *context);
    unsigned int (*check_accesses)(struct damon_ctx *context);
    unsigned int (*apply_probes)(struct damon_ctx *context, bool
set_samples, bool return_max_wsum);
    int (*get_scheme_score)(struct damon_ctx *context, struct
damon_region *r, struct damos *scheme);
    unsigned long (*apply_scheme)(struct damon_ctx *context, struct
damon_target *t, struct damon_region *r, struct damos *scheme, unsigned
long *sz_filter_passed);
    bool (*target_valid)(struct damon_target *t);
    void (*cleanup_target)(struct damon_target *t);
 };

πŸŽ€ Members πŸŽ€

  • id β€” the identifier of this operations set. it's giving social security number, but for ops sets 🫢
  • init β€” initialize the operations-related data structures.
  • update β€” update the operations-related data structures.
  • prepare_access_checks β€” prepare the next access check of target regions.
  • check_accesses β€” check the accesses to target regions.
  • apply_probes β€” apply probes for each region.
  • get_scheme_score β€” get the score of a region for a scheme.
  • apply_scheme β€” apply a DAMON-based operation scheme.
  • target_valid β€” determine if the target is valid.
  • cleanup_target β€” clean up each target before deallocation.

πŸ’– Description πŸ’–

so like, DAMON can be extended for various address spaces and usages β€” it's flexible like that, main character energy fr. for this, users should register the low level operations for their target address space and usecase via the damon_ctx.ops. then the monitoring thread (damon_ctx.kdamond) does a little choreography, and the timing is everything ⭐:

  • it calls init and prepare_access_checks before starting the monitoring
  • update after each damon_attrs.ops_update_interval
  • and check_accesses, target_valid and prepare_access_checks after each damon_attrs.sample_interval

Each struct damon_operations instance having valid id can be registered via damon_register_ops and selected by damon_select_ops later. iconic registration pipeline, no notes πŸ”₯

Now the member-by-member tea β˜•:

  • init should initialize operations-related data structures. for example, this could be used to construct proper monitoring target regions and link those to damon_ctx.adaptive_targets. slay.
  • update should update the operations-related data structures. for example, this could be used to update monitoring target regions for current status. glow-up, but for regions ✨
  • prepare_access_checks should manipulate the monitoring regions to be prepared for the next access check.
  • check_accesses should check the accesses to each region that made after the last preparation and update the number of observed accesses of each region. it should also return max number of observed accesses that made as a result of its update. the value will be used for regions adjustment threshold. lowkey important, don't skip it πŸ‘€
  • apply_probes should apply the data attribute probes to each region and accordingly update the probe hits counter of the region. it should also set damon_region->sampling_addr of each region if set_samples is true. it should also return maximum probe hits weighted sum of regions if return_max_wsum is true. yes, two bool params, she's multitalented πŸ’…
  • get_scheme_score should return the priority score of a region for a scheme as an integer in [0, DAMOS_MAX_SCORE]. bestie, that range is the whole assignment, do not exceed it 😭
  • apply_scheme is called from kdamond when a region for user provided DAMON-based operation scheme is found. it should apply the scheme's action to the region and return bytes of the region that the action is successfully applied. it should also report how many bytes of the region has passed filters (struct damos_filter) that handled by itself. receipts! we love receipts 🧾
  • target_valid should check whether the target is still valid for the monitoring. vibe check on the target, essentially 🌈
  • cleanup_target is called before the target will be deallocated. say bye properly, king 🫑

πŸ¦‹ SEE ALSO πŸ¦‹

Kernel file ./include/linux/damon.h:

  • struct damon_addr_range(9)
  • struct damon_size_range(9)
  • struct damon_region(9)
  • struct damon_target(9)
  • enum damos_action(9)
  • enum damos_quota_goal_metric(9)
  • struct damos_quota_goal(9)
  • enum damos_quota_goal_tuner(9)
  • struct damos_quota(9)
  • enum damos_wmark_metric(9)
  • struct damos_watermarks(9)
  • struct damos_stat(9)
  • enum damos_filter_type(9)
  • struct damos_filter(9)
  • struct damos_walk_control(9)
  • struct damos_access_pattern(9)
  • struct damos_migrate_dests(9)
  • struct damos(9)
  • enum damon_ops_id(9)
  • struct damon_intervals_goal(9)
  • enum damon_filter_type(9)
  • struct damon_filter(9)
  • struct damon_probe(9)
  • struct damon_attrs(9)
  • struct damon_ctx(9)
go read all of them. yes, all of them. i'll know if you skipped πŸ‘€πŸ’€

okay that's the page!! sourced straight from ./include/linux, dated October 2026, and that's a wrap bestie β€” go forth and register your ops πŸŽ€πŸ’–πŸ«Ά

πŸ“¦ where this page comes from