Re: [RFC PATCH 00/18] efficiently expose damos action tried regions information

[SeongJae Park <sj@kernel.org>]

On Wed, 19 Oct 2022 00:12:59 +0000 SeongJae Park <sj@kernel.org> wrote:

> DAMON users can retrieve the monitoring results via 'after_aggregation'
> callbacks if the user is using the kernel API, or 'damon_aggregated'
> tracepoint if the user is in the user space.  Those are useful if full
> monitoring results are necessary.  However, if the user has interest in
> only some regions having specific access pattern, the interfaces could
> be inefficient.  For example, some DAMOS users might want to know
> exactly what regions were identified as fulfilling the access pattern of
> the scheme, for a debugging or a tuning.
> 
> This patchset implements DAMON kernel API callbacks and sysfs directory
> for efficient exposure of the information.  The new callback will be
> called for each region before specific DAMOS action is gonna tried to be
> applied.  The sysfs directory will be called 'tried_regions' and placed
> under each scheme sysfs directory.  User can write a special keyworkd,
> 'update_schemes_regions' to the 'state' file of a kdamond sysfs
> directory.  Then, DAMON sysfs interface will fill the directory with the
> information of regions that corresponding scheme action was tried to be
> applied for one aggregation interval.
> 
> Patches Sequence
> ----------------
> 
> First five patches (1-5) clean up and refactor code that following patch
> will touch, and the following one (patch 6) implements the DAMON
> callback for DAMON kernel API users.
> 
> Following six patches (7-12) clean up and refactor the sysfs interface
> before the new sysfs directory introduction.  Following two patches (13
> and 14) implement the sysfs directories, and successing two patches (15
> and 16) implement the special keyword for 'state' to fill and clean up
> the directories.
> 
> Finally, two more patches (17 and 18) for the documentation of the usage
> and ABI follow.

I think this patchset is unnecessarily big due to the cleanups and
refactorings.  I added them in this patchset mainly because I found the messy
code while working for the feature.  However, now it looks like it would make
more sense to split them out into separate patchsets.

Just thinking loudly, but any input is welcome.


Thanks,
SJ
[...]