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