linux-kernel - Re: [PATCH] mm/damon: Prevent unnecessary age reset for regions

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:   Tue, 8 Aug 2023 18:59:13 +0900
From:   지형탁 <hyeongtak.ji@...il.com>
To:     SeongJae Park <sj@...nel.org>
Cc:     akpm@...ux-foundation.org, damon@...ts.linux.dev,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Hyeongtak Ji <hyeongtak.ji@...com>
Subject: Re: [PATCH] mm/damon: Prevent unnecessary age reset for regions

Hello,

Thank you for your review. I really appreciate it.

On Tue, Aug 8, 2023 at 3:14 AM SeongJae Park <sj@...nel.org> wrote:
>
> Hi Hyeongtak,
>
>
> Thank you for this patch!
>
> On Mon, 7 Aug 2023 18:44:35 +0900 Hyeongtak Ji <hyeongtak.ji@...il.com> wrote:
>
> > DAMON resets the age of each region after applying each scheme,
> > regardless of whether the scheme has been successfully applied.
> >
> > This patch adds a simple condition to prevent the age of regions from
> > being reset when schemes have not been actually applied.
>
> We consider applying the action as making a change to the region, and hence
> reset the age to zero.  Even if the action was not completely applied,
> that might be enough to make some change to the region.  The behavior is also
> to limit a scheme too repeatedly and frequently applied to a region.

This is what I have totally overlooked.

>
> So, this is not a bug but an intended behavior, and I think this change might
> not what really necessary.

Now I understand that this patch is not necessary.

>
> Is there a specific use case that this change is needed?  If so, I think we can
> think about extending the interface to support the case.

Not for now, but if I find any use cases for this situation, I will
let you know.

>
>
> Thanks,
> SJ
>