Re: [PATCH] mm/memcontrol: add memory.peak in cgroup root

[Matthew Chae <matthewc@axis.com>]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

Hi Michal

Thank you for helping me gain full insight.
It looks like there is no proper way to get the peak memory usage 
recorded without adding any overhead to the system and for all users. 
But I fully understand what you kindly explained. Basically, having low 
memory left doesn't mean a bad situation for the system, So checking the 
peak memory doesn't mean a lot and is not necessary.

Let me check again whether we have any special usecase. otherwise, we 
might need to reconsider this requirement.

Thanks,

Matthew

On 2/24/23 09:23, Michal Hocko wrote:
> On Thu 23-02-23 19:00:57, Matthew Chae wrote:
>> Hi Roman,
>>
>> I'd like to get the peak memory usage recorded overall time, rather than at a certain time.
> Sampling /proc/vmstat should have a minimal overhead and you will get
> not only a single value but also a break down to broad cathegory users
> (LRU, slab, page tables etc.). Unfortunatelly this doesn't cover all the
> users (e.g. direct users of the page allocator are not accounted to any
> specific counter) but it should give you a reasonable idea how is memory
> utilized. Specific metrics really depend on what you are interested in.
>
> Another approach that might give you a different angle to the memory
> consumption is to watch PSI metrics. This will not tell you the peak
> memory usage but it will give you an useful cost model for the memory
> usage. Being low on free memory itself is not a bad thing, i.e. you are
> paying for the amount of memory so it would be rather sub-optimal to not
> use it whole, right? If the memory can be reclaimed easily (e.g. by
> reclaiming idle caches) then the overhead of a high memory utilization
> should be reasonably low so the overal price of the reclaim is worth it.
> On the other hand an over utilized system with a working set size larger
> than the available memory would spend a lot of time reclaiming so the
> performance would drop down.
>
> All that being said the primary question is what is your usecase.

[-- Attachment #2: Type: text/html, Size: 2598 bytes --]