How to accout max_rss precisely

[Heran Yang]

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....
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20240616/a4532c7d/attachment.html>