[lkml]   [2021]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v31 05/13] mm/damon: Implement primitives for the virtual memory address spaces
On Mon, Jun 21, 2021 at 1:31 AM SeongJae Park <> wrote:
> From: SeongJae Park <>
> 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>
> <uppermost mmap()-ed region>
> (small mmap()-ed regions and munmap()-ed regions)
> <lowermost mmap()-ed region>
> <stack>
> Signed-off-by: SeongJae Park <>
> Reviewed-by: Leonard Foerster <>
> Reviewed-by: Fernand Sieber <>

Acked-by: Shakeel Butt <>

 \ /
  Last update: 2021-07-01 02:19    [W:0.169 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site