Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     <sj38.park@gmail.com>
CC:     <Jonathan.Cameron@Huawei.com>, <acme@kernel.org>,
        <akpm@linux-foundation.org>, <alexander.shishkin@linux.intel.com>,
        <amit@kernel.org>, <benh@kernel.crashing.org>,
        <brendanhiggins@google.com>, <corbet@lwn.net>, <david@redhat.com>,
        <dwmw@amazon.com>, <elver@google.com>, <fan.du@intel.com>,
        <foersleo@amazon.de>, <greg@kroah.com>, <gthelen@google.com>,
        <guoju.fgj@alibaba-inc.com>, <linux-damon@amazon.com>,
        <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-mm@kvack.org>, <mgorman@suse.de>, <minchan@kernel.org>,
        <mingo@redhat.com>, <namhyung@kernel.org>, <peterz@infradead.org>,
        <riel@surriel.com>, <rientjes@google.com>, <rostedt@goodmis.org>,
        <rppt@kernel.org>, <shakeelb@google.com>, <shuah@kernel.org>,
        <sjpark@amazon.de>, <snu@amazon.de>, <vbabka@suse.cz>,
        <vdavydov.dev@gmail.com>, <zgf574564920@gmail.com>
References: <20210520075629.4332-4-sj38.park@gmail.com>
Subject: Re: [PATCH v29 03/13] mm/damon: Adaptively adjust regions
From:   <sieberf@amazon.com>
Message-ID: <1b30265d-7440-1c94-f625-0087215433ee@amazon.com>
Date:   Tue, 25 May 2021 17:17:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20210520075629.4332-4-sj38.park@gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

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