Re: [EXT] Re: [PATCH v5 2/2] mem: telemetry support for system memory information

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 20 Oct 2022 22:18:27 +0300
Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> wrote:

> > 
> > I will send out a v6 if the above solution is fine.
> >   
> > > 
> > >     
> > > >
> > > > 1. /sysmem/sys_heap_list
> > > > The commands displays the arenas currently in use.
> > > > Example:    
> > > > --> /sysmem/sys_heap_list    
> > > > {"/sysmem/sys_heap_list": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
> > > >    
> > > 
> > > I am unsure about the command names.
> > > 
> > > Those commands are really low level and tied to glibc malloc.
> > > It is unlikely we will have an unified naming with other libc/OS.
> > > 
> > > I would prefer another pair of eyes, especially on this patch.
> > > Dmitry, Anatoly?  
> 
> I agree with David.
> 
> Microsoft CRT provides completely different statistics.
> I can't say for FreeBSD.
> Even if GNU libc is used, the process can be run with jemalloc, for example,
> and this statistics become meaningless then.
> What is "system" memory, anyway? It can be acquired bypassing malloc,
> it can be hugepages mmap'd without DPDK, etc.
> 
> What is the task this API must solve?
> My guess is that monitoring needs to know how much physical memory
> 1) the process uses and 2) how much it can use, so on Linux this API
> could be implemented using getrusage() and getrlimit().
> I don't think that a fully portable implementation is possible,
> but at least API will be unified.


NAK
You are opening a mess here.
The malloc_info() exporting XML also means you have to parse the crap.

Telemetry to should stick to the DPDK environment and not try to support
looking at other parts of the system. Otherwise, it risks becoming
tied to one OS and version.