The purpose of these patches is to add CMA memory monitoring function.
In some memory tight scenarios, it will be a good choice to release more
memory by monitoring the CMA memory.

These patches is only preliminarily for monitoring function, About the
reclaim, it need to do some fixes base on "reclaim.c" and more tests,
I will implement it in the next patch series.


Xin Hao (3):
  mm/damon: rename damon_evenly_split_region()
  mm/damon/paddr: Move "paddr" relative func to ops-common.c file
  mm/damon/sysfs: Add CMA memory monitoring

 include/linux/damon.h |   1 +
 mm/damon/Makefile     |   2 +-
 mm/damon/ops-common.c | 286 ++++++++++++++++++++++++++++++++++++++++++
 mm/damon/ops-common.h |  18 +++
 mm/damon/paddr-cma.c  | 104 +++++++++++++++
 mm/damon/paddr.c      | 246 ------------------------------------
 mm/damon/sysfs.c      |   1 +
 mm/damon/vaddr-test.h |   6 +-
 mm/damon/vaddr.c      |  41 +-----
 9 files changed, 415 insertions(+), 290 deletions(-)
 create mode 100644 mm/damon/paddr-cma.c

--
2.27.0

On 15.03.22 17:37, Xin Hao wrote:

s/minotor/monitor/

> The purpose of these patches is to add CMA memory monitoring function.
> In some memory tight scenarios, it will be a good choice to release more
> memory by monitoring the CMA memory.

I'm sorry, but it's hard to figure out what the target use case should
be. Who will release CMA memory and how? Who will monitor that? What are
the "some memory tight scenarios"? What's the overall design goal?

-- 
Thanks,

David / dhildenb

Hi David,

On 3/16/22 11:09 PM, David Hildenbrand wrote:
> On 15.03.22 17:37, Xin Hao wrote:
>
> s/minotor/monitor/
Thanks,  i will fix it.
>
>> The purpose of these patches is to add CMA memory monitoring function.
>> In some memory tight scenarios, it will be a good choice to release more
>> memory by monitoring the CMA memory.
> I'm sorry, but it's hard to figure out what the target use case should
> be. Who will release CMA memory and how? Who will monitor that? What are
> the "some memory tight scenarios"? What's the overall design goal?
I may not be describing exactly what  i mean，My intention is to find out 
how much of the reserved CMA space is actually used and which is unused,
For those that are not used, I understand that they can be released by 
cma_release(). Of course, This is just a little personal thought that I 
think is helpful for saving memory.
>
-- 
Best Regards!
Xin Hao

On 17.03.22 08:03, Xin Hao wrote:
> Hi David,
> 
> On 3/16/22 11:09 PM, David Hildenbrand wrote:
>> On 15.03.22 17:37, Xin Hao wrote:
>>
>> s/minotor/monitor/
> Thanks,  i will fix it.
>>
>>> The purpose of these patches is to add CMA memory monitoring function.
>>> In some memory tight scenarios, it will be a good choice to release more
>>> memory by monitoring the CMA memory.
>> I'm sorry, but it's hard to figure out what the target use case should
>> be. Who will release CMA memory and how? Who will monitor that? What are
>> the "some memory tight scenarios"? What's the overall design goal?
> I may not be describing exactly what  i mean，My intention is to find out 
> how much of the reserved CMA space is actually used and which is unused,
> For those that are not used, I understand that they can be released by 
> cma_release(). Of course, This is just a little personal thought that I 
> think is helpful for saving memory.

Hm, not quite. We can place movable allocations on cma areas, to be
migrated away once required for allocations via CMA. So just looking at
the pages allocated within a CMA area doesn't really tell you what's
actually going on.

-- 
Thanks,

David / dhildenb

On 3/18/22 12:42 AM, David Hildenbrand wrote:
> On 17.03.22 08:03, Xin Hao wrote:
>> Hi David,
>>
>> On 3/16/22 11:09 PM, David Hildenbrand wrote:
>>> On 15.03.22 17:37, Xin Hao wrote:
>>>
>>> s/minotor/monitor/
>> Thanks,  i will fix it.
>>>> The purpose of these patches is to add CMA memory monitoring function.
>>>> In some memory tight scenarios, it will be a good choice to release more
>>>> memory by monitoring the CMA memory.
>>> I'm sorry, but it's hard to figure out what the target use case should
>>> be. Who will release CMA memory and how? Who will monitor that? What are
>>> the "some memory tight scenarios"? What's the overall design goal?
>> I may not be describing exactly what  i mean，My intention is to find out
>> how much of the reserved CMA space is actually used and which is unused,
>> For those that are not used, I understand that they can be released by
>> cma_release(). Of course, This is just a little personal thought that I
>> think is helpful for saving memory.
> Hm, not quite. We can place movable allocations on cma areas, to be
> migrated away once required for allocations via CMA. So just looking at
> the pages allocated within a CMA area doesn't really tell you what's
> actually going on.

I don't think so,  the damon not looking at the pages allocate, It is 
constantly monitoring who is using CMA area pages through tracking page 
access bit

in the kernel via the kdamond.x thread, So through damon, it can tell us 
about  the hot and cold distribution of CMA memory.

--cc  SeongJae Park <sj@kernel.org>


More about damon, you can refer to this 
link：https://sjp38.github.io/post/damon/ 
<https://sjp38.github.io/post/damon/>

>
-- 
Best Regards!
Xin Hao

On 18.03.22 06:13, xhao@linux.alibaba.com wrote:
> 
> On 3/18/22 12:42 AM, David Hildenbrand wrote:
>> On 17.03.22 08:03, Xin Hao wrote:
>>> Hi David,
>>>
>>> On 3/16/22 11:09 PM, David Hildenbrand wrote:
>>>> On 15.03.22 17:37, Xin Hao wrote:
>>>>
>>>> s/minotor/monitor/
>>> Thanks,  i will fix it.
>>>>> The purpose of these patches is to add CMA memory monitoring function.
>>>>> In some memory tight scenarios, it will be a good choice to release more
>>>>> memory by monitoring the CMA memory.
>>>> I'm sorry, but it's hard to figure out what the target use case should
>>>> be. Who will release CMA memory and how? Who will monitor that? What are
>>>> the "some memory tight scenarios"? What's the overall design goal?
>>> I may not be describing exactly what  i mean，My intention is to find out
>>> how much of the reserved CMA space is actually used and which is unused,
>>> For those that are not used, I understand that they can be released by
>>> cma_release(). Of course, This is just a little personal thought that I
>>> think is helpful for saving memory.
>> Hm, not quite. We can place movable allocations on cma areas, to be
>> migrated away once required for allocations via CMA. So just looking at
>> the pages allocated within a CMA area doesn't really tell you what's
>> actually going on.
> 
> I don't think so,  the damon not looking at the pages allocate, It is 
> constantly monitoring who is using CMA area pages through tracking page 
> access bit
> 
> in the kernel via the kdamond.x thread, So through damon, it can tell us 
> about  the hot and cold distribution of CMA memory.

I'm not sure I follow. With random movable pages being placed on the CMA
area, the mentioned use case of "cma_release()" to release pages doesn't
make sense to me.

I assume I'm missing the big picture -- and that should be properly
documented in the patch description. We don't add stuff just because it
could be used somehow, there should be a clear motivation how it can
actually be used.

-- 
Thanks,

David / dhildenb

On Fri, 18 Mar 2022 09:29:20 +0100 David Hildenbrand <david@redhat.com> wrote:

> On 18.03.22 06:13, xhao@linux.alibaba.com wrote:
> > 
> > On 3/18/22 12:42 AM, David Hildenbrand wrote:
> >> On 17.03.22 08:03, Xin Hao wrote:
> >>> Hi David,
> >>>
> >>> On 3/16/22 11:09 PM, David Hildenbrand wrote:
> >>>> On 15.03.22 17:37, Xin Hao wrote:
> >>>>
> >>>> s/minotor/monitor/
> >>> Thanks,  i will fix it.
> >>>>> The purpose of these patches is to add CMA memory monitoring function.
> >>>>> In some memory tight scenarios, it will be a good choice to release more
> >>>>> memory by monitoring the CMA memory.
> >>>> I'm sorry, but it's hard to figure out what the target use case should
> >>>> be. Who will release CMA memory and how? Who will monitor that? What are
> >>>> the "some memory tight scenarios"? What's the overall design goal?
> >>> I may not be describing exactly what  i mean，My intention is to find out
> >>> how much of the reserved CMA space is actually used and which is unused,
> >>> For those that are not used, I understand that they can be released by
> >>> cma_release(). Of course, This is just a little personal thought that I
> >>> think is helpful for saving memory.
> >> Hm, not quite. We can place movable allocations on cma areas, to be
> >> migrated away once required for allocations via CMA. So just looking at
> >> the pages allocated within a CMA area doesn't really tell you what's
> >> actually going on.
> > 
> > I don't think so,  the damon not looking at the pages allocate, It is 
> > constantly monitoring who is using CMA area pages through tracking page 
> > access bit
> > 
> > in the kernel via the kdamond.x thread, So through damon, it can tell us 
> > about  the hot and cold distribution of CMA memory.
> 
> I'm not sure I follow. With random movable pages being placed on the CMA
> area, the mentioned use case of "cma_release()" to release pages doesn't
> make sense to me.
> 
> I assume I'm missing the big picture -- and that should be properly
> documented in the patch description. We don't add stuff just because it
> could be used somehow, there should be a clear motivation how it can
> actually be used.

Same opinion from my side.  The purpose and usage of this patch is unclear to
me.  Could you please clarify more, Xin?


Thanks,
SJ

> 
> -- 
> Thanks,
> 
> David / dhildenb