On Thu, 11 Nov 2021 10:04:38 +0800 Xin Hao <xhao@xxxxxxxxxxxxxxxxx> wrote:
[-- Attachment #1: Type: text/plain, Size: 8070 bytes --]I understand that you don't want to record all the traces and then process the
Hi Park:
On 2021/11/10 下午9:16, SeongJae Park wrote:
On Wed, 10 Nov 2021 20:13:14 +0800 Xin Hao <xhao@xxxxxxxxxxxxxxxxx> wrote:I think these two variables nr_access & age have different meanings,
In patch "mm/damon: add a tracepoint", it adds aDAMON calculates the age using the address range and nr_accesses of the region,
tracepoint for DAMON, it can monitor each region
for each aggregation interval, Now the region add
a new 'age' variable, some primitive would calculate
the priority of each region as a weight, there put it
into tracepoint, so we can easily track the change of
its value through perf or damon-tools.
which are already in the tracepoint. In other words, user space can calculate
the age on their own. Therefore I thought putting age in the tracepoint as
adding unnecessary information, at the moment of the implementation.
Of course, I would missing some use cases that need this information in the
tracepoint. Furthermore, adding just one more value in the tracepoint wouldn't
incur a real issue. But, I'd like to know why this is necessary and how much
benefit it provides. Xin, could you please share that?
the nr_access only reflect the
period of sample_interval, We may be able to get the change of age
through continuous long-term sampling,
But I think this is not very convenient.
We only need to observe the change of age value a small number of times
to replace the continue sampling of the region.
For example, age has been increasing to 141, but nr_access shows a value
of 0 at a certain time. Through this,we can
conclude that the region has a very low nr_access value for a long time.
huge trace data in user space in order to get the age information, because you
want to save disk space and CPU cycles. Is that correct? If so, I think that
makes sense, and it would be better to put that in the commit message.
Thanks,
SJ
[...]