On Mon, 8 Jun 2020 13:40:37 +0200 SeongJae Park <sjpark@xxxxxxxxxx> wrote: > From: SeongJae Park <sjpark@xxxxxxxxx> > > 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@xxxxxxxxx> > Reviewed-by: Leonard Foerster <foersleo@xxxxxxxxx>
