linux-kernel - Re: [PATCH v29 03/13] mm/damon: Adaptively adjust 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1b30265d-7440-1c94-f625-0087215433ee@amazon.com>
Date:   Tue, 25 May 2021 17:17:05 +0200
From:   <sieberf@...zon.com>
To:     <sj38.park@...il.com>
CC:     <Jonathan.Cameron@...wei.com>, <acme@...nel.org>,
        <akpm@...ux-foundation.org>, <alexander.shishkin@...ux.intel.com>,
        <amit@...nel.org>, <benh@...nel.crashing.org>,
        <brendanhiggins@...gle.com>, <corbet@....net>, <david@...hat.com>,
        <dwmw@...zon.com>, <elver@...gle.com>, <fan.du@...el.com>,
        <foersleo@...zon.de>, <greg@...ah.com>, <gthelen@...gle.com>,
        <guoju.fgj@...baba-inc.com>, <linux-damon@...zon.com>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-mm@...ck.org>, <mgorman@...e.de>, <minchan@...nel.org>,
        <mingo@...hat.com>, <namhyung@...nel.org>, <peterz@...radead.org>,
        <riel@...riel.com>, <rientjes@...gle.com>, <rostedt@...dmis.org>,
        <rppt@...nel.org>, <shakeelb@...gle.com>, <shuah@...nel.org>,
        <sjpark@...zon.de>, <snu@...zon.de>, <vbabka@...e.cz>,
        <vdavydov.dev@...il.com>, <zgf574564920@...il.com>
Subject: Re: [PATCH v29 03/13] mm/damon: Adaptively adjust regions

Hi SeongJae,

The code looks good. Some questions for this patch:

The region merge threshold is computed on the access diff. Should the 
diff threshold be exponential as diffs in low number of access are 
likely to be more important? I.e if the threshold is 5, a region A with 
0 accesses will be merged with a region B with 4 accesses (diff=4), but 
a region C with 50 access won't be merged with a region D with 60 
accesses (diff=10), however it seems to me that keeping a good 
granularity between A and B is more important than between C and D for 
FPR. What do you think?

When the number of regions is less than half max region, region split 
kicks in and doubles the number of region. This means that the number of 
region will grow close to max region, then slowly decay as region 
merges, until it reaches half max regions, then double again. This seems 
to create a non-uniform region number distribution over time, with large 
cycles. Also we do a lot of work when we double and no work otherwise. 
Not sure what's the impact on measurement quality but intuitively seems 
like keeping the number of regions constant over time would yield more 
consistent metrics? How about we rather always split regions at each 
iteration, and for each region we give a split probability?

Kind regards,

--Fernand