How to accout max_rss precisely

[Mulyadi Santosa]

Hi

I think the key here is : when exactly cgroup is created for your program?



On Sun, Jun 16, 2024, 15:53 Heran Yang <herany1999 at gmail.com> wrote:

> Hi, and thanks for your reply. I totally forgot to take the dynamic loader
> into consideration, which is my bad.
>
> But another problem is that the peak value cannot align with the max_rss
> getting from `getrusage` function, which
> is ~1000KiB. I guess that it has some connection with max_rss inheriting,
> but I'm not sure about that. Do you have
> any opinion about it?
>
> 杨贺然 <herany1999 at gmail.com> 于2024年6月4日周二 21:37写道：
>
>> Hi, and thanks for your reply. I totally forgot to take the dynamic
>> loader into consideration, which is my bad.
>>
>> But another problem is that the peak value cannot align with the max_rss
>> getting from `getrusage` function, which
>> is ~1000KiB. I guess that it has some connection with max_rss inheriting,
>> but I'm not sure about that. Do you have
>> any opinion about it?
>>
>> Valdis Klētnieks <valdis.kletnieks at vt.edu> 于2024年6月4日周二 01:44写道：
>>
>>> On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said:
>>>
>>> > // a.c
>>> > int main() {}
>>> >
>>> > It shows that `memory.peak` of this program is ~500KiB, which does not
>>> make
>>> > sense to me.
>>>
>>> Makes sense to me...
>>>
>>> [~] cat > testnull.c
>>>  int main() {}
>>> [~] gcc testnull.c
>>> [~] ldd a.out
>>>         linux-vdso.so.1 (0x00007efc6a650000)
>>>         libc.so.6 => /lib64/libc.so.6 (0x00007efc6a43d000)
>>>         /lib64/ld-linux-x86-64.so.2 (0x00007efc6a652000)
>>> [~] objdump -d a.out
>>>
>>> a.out:     file format elf64-x86-64
>>>
>>>
>>> Disassembly of section .init:
>>>
>>> 0000000000401000 <_init>:
>>>   401000:       f3 0f 1e fa             endbr64
>>>   401004:       48 83 ec 08             sub    $0x8,%rsp
>>>   401008:       48 8b 05 d1 2f 00 00    mov    0x2fd1(%rip),%rax
>>> # 403fe0 <__gmon_start__ at Base>
>>>   40100f:       48 85 c0                test   %rax,%rax
>>>   401012:       74 02                   je     401016 <_init+0x16>
>>>   401014:       ff d0                   call   *%rax
>>>   401016:       48 83 c4 08             add    $0x8,%rsp
>>>   40101a:       c3                      ret
>>>
>>> Disassembly of section .text:
>>>
>>> 0000000000401020 <_start>:
>>>   401020:       f3 0f 1e fa             endbr64
>>>   401024:       31 ed                   xor    %ebp,%ebp
>>>   401026:       49 89 d1                mov    %rdx,%r9
>>>   401029:       5e                      pop    %rsi
>>>   40102a:       48 89 e2                mov    %rsp,%rdx
>>>   40102d:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
>>>   401031:       50                      push   %rax
>>>   401032:       54                      push   %rsp
>>>   401033:       45 31 c0                xor    %r8d,%r8d
>>>   401036:       31 c9                   xor    %ecx,%ecx
>>>   401038:       48 c7 c7 06 11 40 00    mov    $0x401106,%rdi
>>>   40103f:       ff 15 93 2f 00 00       call   *0x2f93(%rip)        #
>>> 403fd8 <__libc_start_main at GLIBC_2.34>
>>>   401045:       f4                      hlt
>>>   401046:       66 2e 0f 1f 84 00 00    cs nopw 0x0(%rax,%rax,1)
>>>   40104d:       00 00 00
>>> (.....)
>>>
>>> Basically, its not *really* a totally null program.  You've got the
>>> dynamic
>>> loader ld-linux running first, which then *doesn't* run main() directly,
>>> but
>>> rather invokes _start, which needs to happen so that __libc_start_main
>>> can get
>>> called and initialize stuff lie stdio, malloc, and other such t hings,
>>> before
>>> it finally calls main().
>>>
>>> Personally, I'm surprised that ld-linux and glibc initialization can
>>> finish
>>> without going over 500k - even more so if shared library text pages are
>>> included in memory.peak.  Somebody  else can wade into that mess, I admit
>>> having been around since kernel 2.5.47 or so, and I never did understand
>>> the
>>> memory accounting for shared text pages....
>>>
>>> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20240616/5aa04d0a/attachment.html>