Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Mon, Jul 27, 2020 at 2:03 AM SeongJae Park wrote:
>
> On Mon, 27 Jul 2020 00:34:54 -0700 Greg Thelen wrote:
>
> > 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.
> [...]
> > > diff --git a/mm/damon.c b/mm/damon.c
> > > index b844924b9fdb..386780739007 100644
> > > --- a/mm/damon.c
> > > +++ b/mm/damon.c
> > > @@ -9,6 +9,9 @@
> [...]
> > > +/*
> > > + * Functions for the access checking of the regions
> > > + */
> > > +
> > > +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)) {
> > > + clear_page_idle(pte_page(*pte));
> > > + set_page_young(pte_page(*pte));
> >
> > While this compiles without support for PG_young and PG_idle, I assume
> > it won't work well because it'd clear pte.young without setting
> > PG_young. And this would mess with vmscan.
>
> You're right, thanks for catching this up! This definitely need to be fixed
> in
> the next spin.
>
> >
> > So this code appears to depend on PG_young and PG_idle, which are
> > currently only available via CONFIG_IDLE_PAGE_TRACKING. DAMON could
> > depend on CONFIG_IDLE_PAGE_TRACKING via Kconfig. But I assume that
> > CONFIG_IDLE_PAGE_TRACKING and CONFIG_DAMON cannot be concurrently used
> > because they'll stomp on each other's use of pte.young, PG_young,
> > PG_idle.
> > So I suspect we want:
> > 1. CONFIG_DAMON to depend on !CONFIG_IDLE_PAGE_TRACKING and vise-versa.
> > 2. PG_young,PG_idle and related helpers to depend on
> >CONFIG_DAMON||CONFIG_IDLE_PAGE_TRACKING.
>
> Awesome insights and suggestions, thanks!
>
> I would like to note that DAMON could be interfered by IDLE_PAGE_TRACKING and
> vmscan, but not vice versa, as DAMON respects PG_idle and PG_young. This
> design came from the weak goal of DAMON. DAMON aims to provide not perfect
> monitoring but only best effort accuracy that would be sufficient for
> performance-centric DRAM level memory management. So, at that time, I thought
> being interfered by IDLE_PAGE_TRACKING and the reclaim logic would not be a
> real problem but letting IDLE_PAGE_TRACKING coexist is somehow beneficial.
> That said, I couldn't find a real benefit of the coexistance yet, and the
> problem of being interference now seems bigger as we will support more cases
> including the page granularity.
>
> Maybe we could make IDLE_PAGE_TRACKING and DAMON coexist but mutual exclusive
> in runtime, if the beneficial of coexistance turns out big. However, I would
> like to make it simple first and optimize the case later if real requirement
> found.
If you are planning to have support for tracking at page granularity
and physical memory monitoring in DAMON then I don't see any benefit
of coexistence of DAMON with IDLE_PAGE_TRACKING. Though I will not
push you to go that route if the code with coexistence is simple
enough.
Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Mon, 27 Jul 2020 00:34:54 -0700 Greg Thelen wrote:
> 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.
[...]
> > diff --git a/mm/damon.c b/mm/damon.c
> > index b844924b9fdb..386780739007 100644
> > --- a/mm/damon.c
> > +++ b/mm/damon.c
> > @@ -9,6 +9,9 @@
[...]
> > +/*
> > + * Functions for the access checking of the regions
> > + */
> > +
> > +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)) {
> > + clear_page_idle(pte_page(*pte));
> > + set_page_young(pte_page(*pte));
>
> While this compiles without support for PG_young and PG_idle, I assume
> it won't work well because it'd clear pte.young without setting
> PG_young. And this would mess with vmscan.
You're right, thanks for catching this up! This definitely need to be fixed in
the next spin.
>
> So this code appears to depend on PG_young and PG_idle, which are
> currently only available via CONFIG_IDLE_PAGE_TRACKING. DAMON could
> depend on CONFIG_IDLE_PAGE_TRACKING via Kconfig. But I assume that
> CONFIG_IDLE_PAGE_TRACKING and CONFIG_DAMON cannot be concurrently used
> because they'll stomp on each other's use of pte.young, PG_young,
> PG_idle.
> So I suspect we want:
> 1. CONFIG_DAMON to depend on !CONFIG_IDLE_PAGE_TRACKING and vise-versa.
> 2. PG_young,PG_idle and related helpers to depend on
>CONFIG_DAMON||CONFIG_IDLE_PAGE_TRACKING.
Awesome insights and suggestions, thanks!
I would like to note that DAMON could be interfered by IDLE_PAGE_TRACKING and
vmscan, but not vice versa, as DAMON respects PG_idle and PG_young. This
design came from the weak goal of DAMON. DAMON aims to provide not perfect
monitoring but only best effort accuracy that would be sufficient for
performance-centric DRAM level memory management. So, at that time, I thought
being interfered by IDLE_PAGE_TRACKING and the reclaim logic would not be a
real problem but letting IDLE_PAGE_TRACKING coexist is somehow beneficial.
That said, I couldn't find a real benefit of the coexistance yet, and the
problem of being interference now seems bigger as we will support more cases
including the page granularity.
Maybe we could make IDLE_PAGE_TRACKING and DAMON coexist but mutual exclusive
in runtime, if the beneficial of coexistance turns out big. However, I would
like to make it simple first and optimize the case later if real requirement
found.
So, I will implement your suggestions in the next spin. If you have different
opinions, please feel free to comment.
Thanks,
SeongJae Park
>
> > + }
> > + *pte = pte_mkold(*pte);
> > + pte_unmap_unlock(pte, ptl);
> > + return;
> > + }
> > +
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > + if (pmd_young(*pmd)) {
> > + clear_page_idle(pmd_page(*pmd));
> > + set_page_young(pmd_page(*pmd));
> > + }
> > + *pmd = pmd_mkold(*pmd);
> > + spin_unlock(ptl);
> > +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> > +}
> > +
[...]
Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt wrote:
> On Mon, Jul 13, 2020 at 1:44 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 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::
> >
> >
> >
> >
> > (small mmap()-ed regions and munmap()-ed regions)
> >
> >
> >
> >
> > Signed-off-by: SeongJae Park
> > Reviewed-by: Leonard Foerster
> [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.
Thanks,
SeongJae Park
>
> > + clear_page_idle(pte_page(*pte));
> > + set_page_young(pte_page(*pte));
> > + }
> > + *pte = pte_mkold(*pte);
> > + pte_unmap_unlock(pte, ptl);
> > + return;
> > + }
> > +
Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
>
> On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt wrote:
>
> > On Mon, Jul 13, 2020 at 1:44 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 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::
> > >
> > >
> > >
> > >
> > > (small mmap()-ed regions and munmap()-ed regions)
> > >
> > >
> > >
> > >
> > > Signed-off-by: SeongJae Park
> > > Reviewed-by: Leonard Foerster
> > [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(). 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.
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?
Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Tue, 28 Jul 2020 10:42:11 -0700 Shakeel Butt wrote:
> On Mon, Jul 27, 2020 at 2:03 AM SeongJae Park wrote:
> >
> > On Mon, 27 Jul 2020 00:34:54 -0700 Greg Thelen wrote:
> >
> > > 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.
> > [...]
> > > > diff --git a/mm/damon.c b/mm/damon.c
> > > > index b844924b9fdb..386780739007 100644
> > > > --- a/mm/damon.c
> > > > +++ b/mm/damon.c
> > > > @@ -9,6 +9,9 @@
> > [...]
> > > > +/*
> > > > + * Functions for the access checking of the regions
> > > > + */
> > > > +
> > > > +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)) {
> > > > + clear_page_idle(pte_page(*pte));
> > > > + set_page_young(pte_page(*pte));
> > >
> > > While this compiles without support for PG_young and PG_idle, I assume
> > > it won't work well because it'd clear pte.young without setting
> > > PG_young. And this would mess with vmscan.
> >
> > You're right, thanks for catching this up! This definitely need to be
> > fixed in
> > the next spin.
> >
> > >
> > > So this code appears to depend on PG_young and PG_idle, which are
> > > currently only available via CONFIG_IDLE_PAGE_TRACKING. DAMON could
> > > depend on CONFIG_IDLE_PAGE_TRACKING via Kconfig. But I assume that
> > > CONFIG_IDLE_PAGE_TRACKING and CONFIG_DAMON cannot be concurrently used
> > > because they'll stomp on each other's use of pte.young, PG_young,
> > > PG_idle.
> > > So I suspect we want:
> > > 1. CONFIG_DAMON to depend on !CONFIG_IDLE_PAGE_TRACKING and vise-versa.
> > > 2. PG_young,PG_idle and related helpers to depend on
> > >CONFIG_DAMON||CONFIG_IDLE_PAGE_TRACKING.
> >
> > Awesome insights and suggestions, thanks!
> >
> > I would like to note that DAMON could be interfered by IDLE_PAGE_TRACKING
> > and
> > vmscan, but not vice versa, as DAMON respects PG_idle and PG_young. This
> > design came from the weak goal of DAMON. DAMON aims to provide not perfect
> > monitoring but only best effort accuracy that would be sufficient for
> > performance-centric DRAM level memory management. So, at that time, I
> > thought
> > being interfered by IDLE_PAGE_TRACKING and the reclaim logic would not be a
> > real problem but letting IDLE_PAGE_TRACKING coexist is somehow beneficial.
> > That said, I couldn't find a real benefit of the coexistance yet, and the
> > problem of being interference now seems bigger as we will support more cases
> > including the page granularity.
> >
> > Maybe we could make IDLE_PAGE_TRACKING and DAMON coexist but mutual
> > exclusive
> > in runtime, if the beneficial of coexistance turns out big. However, I
> > would
> > like to make it simple first and optimize the case later if real requirement
> > found.
>
> If you are planning to have support for tracking at page granularity
> and physical memory monitoring in DAMON then I don't see any benefit
> of coexistence of DAMON with IDLE_PAGE_TRACKING. Though I will not
> push you to go that route if the code with coexistence is simple
> enough.
Agreed, I don't see the benefit, neither. I already selected the mutual
exclusive way :)
Thanks,
SeongJae Park
Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Fri, Jul 17, 2020 at 9:24 AM SeongJae Park wrote:
>
> On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt wrote:
>
> > On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
> > >
> > > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt
> > > wrote:
> > >
> > > > On Mon, Jul 13, 2020 at 1:44 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 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::
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > (small mmap()-ed regions and munmap()-ed regions)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Signed-off-by: SeongJae Park
> > > > > Reviewed-by: Leonard Foerster
> > > > [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 aft
Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt wrote:
> On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
> >
> > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt wrote:
> >
> > > On Mon, Jul 13, 2020 at 1:44 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 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::
> > > >
> > > >
> > > >
> > > >
> > > > (small mmap()-ed regions and munmap()-ed regions)
> > > >
> > > >
> > > >
> > > >
> > > > Signed-off-by: SeongJae Park
> > > > Reviewed-by: Leonard Foerster
> > > [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.0...@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 t
Re: Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
On Fri, 17 Jul 2020 19:23:28 -0700 Shakeel Butt wrote:
> On Fri, Jul 17, 2020 at 9:24 AM SeongJae Park wrote:
> >
> > On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt wrote:
> >
> > > On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
> > > >
> > > > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt
> > > > wrote:
> > > >
> > > > > On Mon, Jul 13, 2020 at 1:44 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 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::
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > (small mmap()-ed regions and munmap()-ed regions)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Signed-off-by: SeongJae Park
> > > > > > Reviewed-by: Leonard Foerster
> > > > > [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 si
