lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 11 Nov 2021 16:29:23 +0800
From:   Xin Hao <xhao@...ux.alibaba.com>
To:     SeongJae Park <sj@...nel.org>
Cc:     sjpark@...zon.de, akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V1 2/2] mm/damon: Add 'age' of region tracepoint support

Hi, Park:

On 2021/11/11 下午4:20, SeongJae Park wrote:
> On Thu, 11 Nov 2021 10:04:38 +0800 Xin Hao <xhao@...ux.alibaba.com> wrote:
>
>> [-- Attachment #1: Type: text/plain, Size: 8070 bytes --]
>>
>> Hi Park:
>>
>> On 2021/11/10 下午9:16, SeongJae Park wrote:
>>> On Wed, 10 Nov 2021 20:13:14 +0800 Xin Hao <xhao@...ux.alibaba.com> wrote:
>>>
>>>> In patch "mm/damon: add a tracepoint", it adds a
>>>> 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.
>>> DAMON calculates the age using the address range and nr_accesses of the region,
>>> 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?
>> I think these two variables nr_access &  age have different meanings,
>> 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.
> I understand that you don't want to record all the traces and then process the
> 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.

Yes, What you said is absolutely correct, that's how I thought about it, 
I will add this part of the

information to the commit,thanks!

>
>
> Thanks,
> SJ
>
> [...]

-- 
Best Regards!
Xin Hao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ