Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces

[SeongJae Park <sjpark@amazon.com>]

On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt <shakeelb@google.com> wrote:

> On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park <sjpark@amazon.com> wrote:
> >
> > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt <shakeelb@google.com> wrote:
> >
> > > On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park <sjpark@amazon.com> wrote:
> > > >
> > > > From: SeongJae Park <sjpark@amazon.de>
> > > >
> > > > 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 provided by
> > > > this commit is designed 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 next sampling target page and checks whether
> > > > it set again after one sampling period.  To avoid disturbing other
> > > > Accessed bit users such as the reclamation logic, the implementation
> > > > adjusts the ``PG_Idle`` and ``PG_Young`` appropriately, as same to the
> > > > 'Idle Page Tracking'.
> > > >
> > > > 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 spacees, 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@amazon.de>
> > > > Reviewed-by: Leonard Foerster <foersleo@amazon.de>
> > > [snip]
> > > > +
> > > > +static void damon_mkold(struct mm_struct *mm, unsigned long addr)
> > > > +{
> > > > +       pte_t *pte = NULL;
> > > > +       pmd_t *pmd = NULL;
> > > > +       spinlock_t *ptl;
> > > > +
> > > > +       if (follow_pte_pmd(mm, addr, NULL, &pte, &pmd, &ptl))
> > > > +               return;
> > > > +
> > > > +       if (pte) {
> > > > +               if (pte_young(*pte)) {
> > >
> > > Any reason for skipping mmu_notifier_clear_young()? Why exclude VMs as
> > > DAMON's target applications?
> >
> > Obviously my mistake, thank you for pointing this!  I will add the function
> > call in the next spin.
> >
> 
> Similarly mmu_notifier_test_young() for the damon_young().

Yes, indeed.  Thanks for pointing this, either :)

> BTW I think we can combine ctx->prepare_access_checks() and
> ctx->check_accesses() into one i.e. get the young state for the previous
> cycle and mkold for the next cycle in a single step.

Yes, we could.  But, I'm unsure what is the advantage of doing that.  First of
all, if the combined implementation is required, peopld could simply implement
the two logics in the combined way in one of the callbacks and leave the other
one blank.  Also, I'm worrying if combining those could make the code a little
bit hard to read.  IMHO, I think separating those makes the 'kdamond_fn()' code
little bit easier to read.  Actually, I started from the combined approach but
separated the two logics since v7 after Jonathan's comment[1].


[1] https://lore.kernel.org/linux-mm/20200310085721.00000a0f@Huawei.com/


> 
> I am wondering if there is any advantage to having "Page Idle
> Tracking" beside DAMON. I think we can make them mutually exclusive.
> Once we have established that I think DAMON can steal the two page
> flag bits from it and can make use of them. What do you think?

Again, yes, I think we could.  But I don't see clear advantage of it for now.


Thanks,
SeongJae Park