Hi
I think the key here is : when exactly cgroup is created for your program?
On Sun, Jun 16, 2024, 15:53 Heran Yang <herany1...@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?
>
> 杨贺然 <herany1...@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.kletni...@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__@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@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
