linux-kernel - Re: [PATCH v15 04/14] 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: <20200610101324.20437-1-sjpark@amazon.com>
Date:   Wed, 10 Jun 2020 12:13:24 +0200
From:   SeongJae Park <sjpark@...zon.com>
To:     SeongJae Park <sjpark@...zon.com>
CC:     <akpm@...ux-foundation.org>, SeongJae Park <sjpark@...zon.de>,
        <Jonathan.Cameron@...wei.com>, <aarcange@...hat.com>,
        <acme@...nel.org>, <alexander.shishkin@...ux.intel.com>,
        <amit@...nel.org>, <benh@...nel.crashing.org>,
        <brendan.d.gregg@...il.com>, <brendanhiggins@...gle.com>,
        <cai@....pw>, <colin.king@...onical.com>, <corbet@....net>,
        <dwmw@...zon.com>, <foersleo@...zon.de>, <irogers@...gle.com>,
        <jolsa@...hat.com>, <kirill@...temov.name>, <mark.rutland@....com>,
        <mgorman@...e.de>, <minchan@...nel.org>, <mingo@...hat.com>,
        <namhyung@...nel.org>, <peterz@...radead.org>,
        <rdunlap@...radead.org>, <riel@...riel.com>, <rientjes@...gle.com>,
        <rostedt@...dmis.org>, <sblbir@...zon.com>, <shakeelb@...gle.com>,
        <shuah@...nel.org>, <sj38.park@...il.com>, <snu@...zon.de>,
        <vbabka@...e.cz>, <vdavydov.dev@...il.com>,
        <yang.shi@...ux.alibaba.com>, <ying.huang@...el.com>,
        <david@...hat.com>, <linux-damon@...zon.com>, <linux-mm@...ck.org>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v15 04/14] mm/damon: Adaptively adjust regions

On Mon, 8 Jun 2020 13:40:37 +0200 SeongJae Park <sjpark@...zon.com> wrote:

> From: SeongJae Park <sjpark@...zon.de>
> 
> At the beginning of the monitoring, DAMON constructs the initial regions
> by evenly splitting the memory mapped address space of the process into
> the user-specified minimal number of regions.  In this initial state,
> the assumption of the regions (pages in same region have similar access
> frequencies) is normally not kept and thus the monitoring quality could
> be low.  To keep the assumption as much as possible, DAMON adaptively
> merges and splits each region.
> 
> For each ``aggregation interval``, it compares the access frequencies of
> adjacent regions and merges those if the frequency difference is small.
> Then, after it reports and clears the aggregated access frequency of
> each region, it splits each region into two regions if the total number
> of regions is smaller than the half of the user-specified maximum number
> of regions.

I recently realized that only the 'maximum number of regions' is respected,
meanwhile the 'minimum number of regions' isn't.  In the next spin, I will
update the code to 1) set new internal variable, 'max_sz_region' as size of
entire monitoring target regions divided by the 'minimum number of regions',
and 2) avoid merging regions if it results in region of size larger than that.

This change would make DAMON more flexible for special cases.  For example,
some use cases would need static granularity monitoring.  In such case, users
will be able to adjust the granularity by controlling the 'minimum number of
regions', and avoid the split/merge of regions by setting the 'maximum number
of regions' as same to the 'minimum number of regions'.


Thanks,
SeongJae Park

> 
> In this way, DAMON provides its best-effort quality and minimal overhead
> while keeping the bounds users set for their trade-off.
> 
> Signed-off-by: SeongJae Park <sjpark@...zon.de>
> Reviewed-by: Leonard Foerster <foersleo@...zon.de>