On Wed, Jun 30, 2021 at 5:18 PM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > On Mon, Jun 21, 2021 at 1:31 AM SeongJae Park <sj38.park@xxxxxxxxx> wrote: > > > > From: SeongJae Park <sjpark@xxxxxxxxx> > > > > This commit introduces a reference implementation of the address space > > specific low level primitives for the virtual address space, so that > > users of DAMON can easily monitor the data accesses on virtual address > > spaces of specific processes by simply configuring the implementation to > > be used by DAMON. > > > > The low level primitives for the fundamental access monitoring are > > defined in two parts: > > > > 1. Identification of the monitoring target address range for the address > > space. > > 2. Access check of specific address range in the target space. > > > > The reference implementation for the virtual address space does the > > works as below. > > > > PTE Accessed-bit Based Access Check > > ----------------------------------- > > > > The implementation uses PTE Accessed-bit for basic access checks. That > > is, it clears the bit for the next sampling target page and checks > > whether it is set again after one sampling period. This could disturb > > the reclaim logic. DAMON uses ``PG_idle`` and ``PG_young`` page flags > > to solve the conflict, as Idle page tracking does. > > > > VMA-based Target Address Range Construction > > ------------------------------------------- > > > > Only small parts in the super-huge virtual address space of the > > processes are mapped to physical memory and accessed. Thus, tracking > > the unmapped address regions is just wasteful. However, because DAMON > > can deal with some level of noise using the adaptive regions adjustment > > mechanism, tracking every mapping is not strictly required but could > > even incur a high overhead in some cases. That said, too huge unmapped > > areas inside the monitoring target should be removed to not take the > > time for the adaptive mechanism. > > > > For the reason, this implementation converts the complex mappings to > > three distinct regions that cover every mapped area of the address > > space. Also, the two gaps between the three regions are the two biggest > > unmapped areas in the given address space. The two biggest unmapped > > areas would be the gap between the heap and the uppermost mmap()-ed > > region, and the gap between the lowermost mmap()-ed region and the stack > > in most of the cases. Because these gaps are exceptionally huge in > > usual address spaces, excluding these will be sufficient to make a > > reasonable trade-off. Below shows this in detail:: > > > > <heap> > > <BIG UNMAPPED REGION 1> > > <uppermost mmap()-ed region> > > (small mmap()-ed regions and munmap()-ed regions) > > <lowermost mmap()-ed region> > > <BIG UNMAPPED REGION 2> > > <stack> > > > > Signed-off-by: SeongJae Park <sjpark@xxxxxxxxx> > > Reviewed-by: Leonard Foerster <foersleo@xxxxxxxxx> > > Reviewed-by: Fernand Sieber <sieberf@xxxxxxxxxx> > > Acked-by: Shakeel Butt <shakeelb@xxxxxxxxxx> Ok that was by mistake. The ACK is for v32.
