Re: How to accout max_rss precisely

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 于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@xxxxxx> 于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__@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@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@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

  Powered by Linux