Re: [PATCH v29 05/13] mm/damon: Implement primitives for the virtual memory address spaces

[SeongJae Park]

From: SeongJae Park <sjpark@xxxxxxxxx>

On Tue, 25 May 2021 17:19:04 +0200 <sieberf@xxxxxxxxxx> wrote:

> Hi SeongJae,
> 
> Some questions for this patch:
> 
> Why do we split the regions in 3 areas (heap, stack, mmaped)? I 
> understand we don't want to model the whole virtual address space, but 
> why don't we just use whatever is modeled by the VMAs to define the 
> regions boundaries?

First of all, number of VMAs could be very large in some processes.  Also, VMAs
could have small gaps between them so that our merge/split strategy doesn't
works effectively.

> 
> I am not quite understanding why we both set the page idle and young (in 
> damon_ptep_mkold). For WSS computation on our end we have used 
> pte_clear_young_notify. Why do we touch the page idle flag at all? What 
> flags do the reclaim logic use to track access?

Both DAMON and reclaim logic read and write 'Accessed' bits in page table
entries to check if a page is accessed or not.  Because this could let them
interfere each other, we have two per-page flags called PG_Idle and PG_Young,
which save the original state of the 'Accessed' bit.

For example, if DAMON needs to clear 'Accessed' bit of a page, it first sees if
the page accessed.  Because simply clearing the bit could make the reclaim
logic thinks the page was not accessed, it sets PG_Young in this case.  Later,
when reclaim logic needs to check if the page is accessed or not, it first
reads the 'Accessed' bit, which cleared by DAMON, and finds it's not set.  But,
reclaim logic checks PG_Young together, which set by DAMON, so it knows the
page has accessed.  This also means PG_Young should cleared by reclaim logic,
when it clears 'Accessed' bit.  Similarly, DAMON sets PG_Idle when it clears
'Accessed' bit.  And, vice versa for reclaim logic.

Hope these answer your questions.  If something unclear or I missed some of
your point, please feel free to let me know.


Thanks,
SeongJae Park

> 
> Kind regards,
> 
> Fernand