Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature

[SeongJae Park]

On Sun, 28 Jan 2024 17:13:00 +0800 cuiyangpei <cuiyangpei@xxxxxxxxx> wrote:

> On Fri, Jan 26, 2024 at 12:04:54AM -0800, SeongJae Park wrote:
[...]
> > So, 'update_schemes_tried_regions' command is firstly handled by
> > 'damon_sysfs_cmd_request_callback()', which is registered as
> > after_wmarks_check() and after_aggregation() callback.  Hence
> > 'update_schemes_tried_regions' command is still effectively working in
> > aggregation interval granularity.  I think this is what you found, right?
> > 
> Yes.
> > If I'm not wrongly understanding your point, I think the concern is valid.  I
> > think we should make it works in sampling interval granularity.  I will try to
> > make so.  Would that work for your use case?
> > 
> It's much better than working in aggregation interval.

Thank you for confirming.  I will start working on this.

> 
> I have a question. Why does the 'update_schemes_tried_regions' command need to work
> in the sampling time or aggregation time? 'update_schemes_tried_regions' is a
> relatively special state that updates the regions that corresponding operation scheme.
> Can it be separated from other states and controlled by sysfs node to respond immediately
> after being written?

Mainly because the region data is updated by a kdamond thread.  To safely
access the region, the accessor should do some kind of synchronization with the
kdamond thread.  To minimize such synchronization overhead, DAMON let the API
users (kernel components) to register callbacks which kdamond invokes under
specific events including 'after_sampling' or 'after_aggregate'.  Because the
callback is executed in the kdamond thread, callbacks can safely access the
data without additional synchronization.  DAMON sysfs interface is using the
callback mechanism, and hence need to work in the sampling or aggregation
times.


Thanks,
SJ

[...]