about DAMON lru_sort

about DAMON lru_sort

[Xin Hao]

Hi sj,

     I have seen the DAMON + LRU codes detailedly， i really think it is 
a good idea, but i have a few question,  why we can not to monitor whole 
per node zone automatically,  i think it is hard to pass a physical 
address when you do not  sure which physical address range to choose.

     for example,  i do not care which physical address range need to be 
minitored, i just want know the whole memory which includes how much 
inactive pages and

to better reclaim them.

     I just put forward my idea in a superficial way and look forward to 
your reply，thanks.

-- 
Best Regards!
Xin Hao

Re: about DAMON lru_sort

[SeongJae Park]

Hi Xin,

On Wed, 15 Jun 2022 17:50:16 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:

> Hi sj,
> 
>      I have seen the DAMON + LRU codes detailedly， i really think it is 
> a good idea, but i have a few question,  why we can not to monitor whole 
> per node zone automatically,  i think it is hard to pass a physical 
> address when you do not  sure which physical address range to choose.
> 
>      for example,  i do not care which physical address range need to be 
> minitored, i just want know the whole memory which includes how much 
> inactive pages and
> 
> to better reclaim them.

Thank you for this question, Xin!  For the use case, I think you can get the
physical address range for the whole memory using '/proc/iomem' or similar
things[1].  If you could use DAMON_LRU_SORT module instead of manually using
DAMOS with DAMOS_LRU_(DE)PRIO action, you can further reduce such efforts,
because it tries to cover almost whole memory by default[2].  If I'm missing
something, please let me know.

[1] https://github.com/awslabs/damo/blob/next/_damo_paddr_layout.py#L135
[2] https://git.kernel.org/pub/scm/linux/kernel/git/sj/linux.git/tree/mm/damon/lru_sort.c?h=damon/next-2022-06-09-19-55-on-v5.19-rc1-mm-unstable#n277


Thanks,
SJ

> 
>      I just put forward my idea in a superficial way and look forward to 
> your reply，thanks.
> 
> -- 
> Best Regards!
> Xin Hao

Re: about DAMON lru_sort

[Xin Hao]

Hi sj,

On 6/16/22 12:51 AM, SeongJae Park wrote:
> Hi Xin,
>
> On Wed, 15 Jun 2022 17:50:16 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
>
>> Hi sj,
>>
>>       I have seen the DAMON + LRU codes detailedly， i really think it is
>> a good idea, but i have a few question,  why we can not to monitor whole
>> per node zone automatically,  i think it is hard to pass a physical
>> address when you do not  sure which physical address range to choose.
>>
>>       for example,  i do not care which physical address range need to be
>> minitored, i just want know the whole memory which includes how much
>> inactive pages and
>>
>> to better reclaim them.
> Thank you for this question, Xin!  For the use case, I think you can get the
> physical address range for the whole memory using '/proc/iomem' or similar
> things[1].  If you could use DAMON_LRU_SORT module instead of manually using
> DAMOS with DAMOS_LRU_(DE)PRIO action, you can further reduce such efforts,
> because it tries to cover almost whole memory by default[2].  If I'm missing
> something, please let me know.

Yes, you are right,  I know what your mean,  The only difference is that 
you manually find the physical address

to monitor, and another is damon automatically helps me get the physical 
address of all the zone to check. I prefer the latter

，why not support them both ?





>
> [1] https://github.com/awslabs/damo/blob/next/_damo_paddr_layout.py#L135
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sj/linux.git/tree/mm/damon/lru_sort.c?h=damon/next-2022-06-09-19-55-on-v5.19-rc1-mm-unstable#n277
>
>
> Thanks,
> SJ
>
>>       I just put forward my idea in a superficial way and look forward to
>> your reply，thanks.
>>
>> -- 
>> Best Regards!
>> Xin Hao

-- 
Best Regards!
Xin Hao

Re: about DAMON lru_sort

[Xin Hao]

Hi sj,

I have another question,  if the mglru patch merge into upstream, which 
is more accurate, whether it can be proved with test data, or 
combination them to use ?

On 6/16/22 12:51 AM, SeongJae Park wrote:
> Hi Xin,
>
> On Wed, 15 Jun 2022 17:50:16 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
>
>> Hi sj,
>>
>>       I have seen the DAMON + LRU codes detailedly， i really think it is
>> a good idea, but i have a few question,  why we can not to monitor whole
>> per node zone automatically,  i think it is hard to pass a physical
>> address when you do not  sure which physical address range to choose.
>>
>>       for example,  i do not care which physical address range need to be
>> minitored, i just want know the whole memory which includes how much
>> inactive pages and
>>
>> to better reclaim them.
> Thank you for this question, Xin!  For the use case, I think you can get the
> physical address range for the whole memory using '/proc/iomem' or similar
> things[1].  If you could use DAMON_LRU_SORT module instead of manually using
> DAMOS with DAMOS_LRU_(DE)PRIO action, you can further reduce such efforts,
> because it tries to cover almost whole memory by default[2].  If I'm missing
> something, please let me know.
>
> [1] https://github.com/awslabs/damo/blob/next/_damo_paddr_layout.py#L135
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sj/linux.git/tree/mm/damon/lru_sort.c?h=damon/next-2022-06-09-19-55-on-v5.19-rc1-mm-unstable#n277
>
>
> Thanks,
> SJ
>
>>       I just put forward my idea in a superficial way and look forward to
>> your reply，thanks.
>>
>> -- 
>> Best Regards!
>> Xin Hao

-- 
Best Regards!
Xin Hao

Re: about DAMON lru_sort

[SeongJae Park]

Hi Xin,

On Fri, 17 Jun 2022 10:47:22 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:

> Hi sj,
> 
> On 6/16/22 12:51 AM, SeongJae Park wrote:
> > Hi Xin,
> >
> > On Wed, 15 Jun 2022 17:50:16 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
> >
> >> Hi sj,
> >>
> >>       I have seen the DAMON + LRU codes detailedly， i really think it is
> >> a good idea, but i have a few question,  why we can not to monitor whole
> >> per node zone automatically,  i think it is hard to pass a physical
> >> address when you do not  sure which physical address range to choose.
> >>
> >>       for example,  i do not care which physical address range need to be
> >> minitored, i just want know the whole memory which includes how much
> >> inactive pages and
> >>
> >> to better reclaim them.
> > Thank you for this question, Xin!  For the use case, I think you can get the
> > physical address range for the whole memory using '/proc/iomem' or similar
> > things[1].  If you could use DAMON_LRU_SORT module instead of manually using
> > DAMOS with DAMOS_LRU_(DE)PRIO action, you can further reduce such efforts,
> > because it tries to cover almost whole memory by default[2].  If I'm missing
> > something, please let me know.
> 
> Yes, you are right,  I know what your mean,  The only difference is that 
> you manually find the physical address
> 
> to monitor, and another is damon automatically helps me get the physical 
> address of all the zone to check. I prefer the latter
> 
> ，why not support them both ?

So you're suggesting adding a change for DAMON sysfs interface that can help
users set the whole physical address space as the target area in more
convenient way, e.g., setting the whole physical address space as the default
for the 'paddr' monitoring ops, right?  Good point.  I think there's no reason
to not do so in general.  I'm wondering if the default values approach could be
shown as an unexpected behavior change to some users, though.


Thanks,
SJ

[...]

Re: about DAMON lru_sort

[SeongJae Park]

Hi Xin,

On Fri, 17 Jun 2022 18:00:30 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:

> Hi sj,
> 
> I have another question,  if the mglru patch merge into upstream, which 
> is more accurate, whether it can be proved with test data, or 
> combination them to use ?

I think a fair comparison should be made with fair amount of combinations, of
course.

I'm unsure if I'm fully understanding your question.  Could you please clarify
your points?


Thanks,
SJ
[...]

Re: about DAMON lru_sort

[Xin Hao]

Hi sj,

On 6/18/22 1:04 AM, SeongJae Park wrote:
> Hi Xin,
>
> On Fri, 17 Jun 2022 18:00:30 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
>
>> Hi sj,
>>
>> I have another question,  if the mglru patch merge into upstream, which
>> is more accurate, whether it can be proved with test data, or
>> combination them to use ?
> I think a fair comparison should be made with fair amount of combinations, of
> course.
>
> I'm unsure if I'm fully understanding your question.  Could you please clarify
> your points?

I spent some time comparing damon and mglru, I was curious to see how 
each of them would play out in the memory reclamation scenario, or if 
each had its own appropriate scenario，so If I want to reclaim memory in 
my service, which one do I choose between damon and mglru?, i think 
others people know about them also have the same confusion.

 From my humble point of view, I think damon is suitable for long cycle, 
targeted active reclaim or others, and mglru  is suitable for the whole 
system.








>
> Thanks,
> SJ
> [...]

-- 
Best Regards!
Xin Hao

Re: about DAMON lru_sort

[SeongJae Park]

Hi Xin,

On Sat, 18 Jun 2022 23:17:02 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:

> Hi sj,
> 
> On 6/18/22 1:04 AM, SeongJae Park wrote:
> > Hi Xin,
> >
> > On Fri, 17 Jun 2022 18:00:30 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
> >
> >> Hi sj,
> >>
> >> I have another question,  if the mglru patch merge into upstream, which
> >> is more accurate, whether it can be proved with test data, or
> >> combination them to use ?
> > I think a fair comparison should be made with fair amount of combinations, of
> > course.
> >
> > I'm unsure if I'm fully understanding your question.  Could you please clarify
> > your points?
> 
> I spent some time comparing damon and mglru, I was curious to see how 
> each of them would play out in the memory reclamation scenario, or if 
> each had its own appropriate scenario，so If I want to reclaim memory in 
> my service, which one do I choose between damon and mglru?, i think 
> others people know about them also have the same confusion.
> 
>  From my humble point of view, I think damon is suitable for long cycle, 
> targeted active reclaim or others, and mglru  is suitable for the whole 
> system.

Please note that I haven't read MGLRU patches in detail, and therefore some of
my answers might wrong.  To my humble understanding, MGLRU is an approach for
making the page granularity access scanning more lightweight and the LRU lists
finer grained.  DAMON_LRU_SORT is a similar approach.  I think the differences
are the method of access scanning and proactiveness.

MGLRU uses an optimized form of page granularity access scanning, so it would
provide quite accurate results but the overhead could increase as the size of
the memory to scan increase.  Meanwhile, DAMON provides upperbound limited
overhead but its accuracy could relatively lower than page granularity
approaches.  Also, DAMON is designed for finding not only cold pages but also
hot pages (by default, DAMON conceptually scans all memory every 5ms).

MGLRU works in the reactive manner as similar to current reclaim logic, though
it provides a way to proactively incur the LRU-lists sorting (or, aging).  That
is, LRU lists would not be well prepared when the first aging of MGLRU is
incurred.  DAMON_LRU_SORT is for making LRU lists proactively prepared for
later uses including reclaim.

Therefore, I think using DAMON_LRU_SORT together with MGLRU would make sense.
In the case, DAMON_LRU_SORT makes LRU-lists more prepared for later reclamation
before the first aging, and MGLRU will make the later reclaim more efficient.


Thanks,
SJ

[...]

Re: about DAMON lru_sort

[Xin Hao]

On 6/19/22 6:14 AM, SeongJae Park wrote:
> Hi Xin,
>
> On Sat, 18 Jun 2022 23:17:02 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
>
>> Hi sj,
>>
>> On 6/18/22 1:04 AM, SeongJae Park wrote:
>>> Hi Xin,
>>>
>>> On Fri, 17 Jun 2022 18:00:30 +0800 Xin Hao <xhao@linux.alibaba.com> wrote:
>>>
>>>> Hi sj,
>>>>
>>>> I have another question,  if the mglru patch merge into upstream, which
>>>> is more accurate, whether it can be proved with test data, or
>>>> combination them to use ?
>>> I think a fair comparison should be made with fair amount of combinations, of
>>> course.
>>>
>>> I'm unsure if I'm fully understanding your question.  Could you please clarify
>>> your points?
>> I spent some time comparing damon and mglru, I was curious to see how
>> each of them would play out in the memory reclamation scenario, or if
>> each had its own appropriate scenario，so If I want to reclaim memory in
>> my service, which one do I choose between damon and mglru?, i think
>> others people know about them also have the same confusion.
>>
>>   From my humble point of view, I think damon is suitable for long cycle,
>> targeted active reclaim or others, and mglru  is suitable for the whole
>> system.
> Please note that I haven't read MGLRU patches in detail, and therefore some of
> my answers might wrong.  To my humble understanding, MGLRU is an approach for
> making the page granularity access scanning more lightweight and the LRU lists
> finer grained.  DAMON_LRU_SORT is a similar approach.  I think the differences
> are the method of access scanning and proactiveness.
>
> MGLRU uses an optimized form of page granularity access scanning, so it would
> provide quite accurate results but the overhead could increase as the size of
> the memory to scan increase.  Meanwhile, DAMON provides upperbound limited
> overhead but its accuracy could relatively lower than page granularity
> approaches.  Also, DAMON is designed for finding not only cold pages but also
> hot pages (by default, DAMON conceptually scans all memory every 5ms).
>
> MGLRU works in the reactive manner as similar to current reclaim logic, though
> it provides a way to proactively incur the LRU-lists sorting (or, aging).  That
> is, LRU lists would not be well prepared when the first aging of MGLRU is
> incurred.  DAMON_LRU_SORT is for making LRU lists proactively prepared for
> later uses including reclaim.
>
> Therefore, I think using DAMON_LRU_SORT together with MGLRU would make sense.
> In the case, DAMON_LRU_SORT makes LRU-lists more prepared for later reclamation
> before the first aging, and MGLRU will make the later reclaim more efficient.
Ok, Thank you very much for your detailed reply.
>
>
> Thanks,
> SJ
>
> [...]

-- 
Best Regards!
Xin Hao