Hi!
I do this test leverage systemd-run. The command likes:
systemd-run --user --unit test --wait ./a
Though there are some accounting bugs in systemd-run (check PR #33258), the accounting value is aligned
with cgroups. The cgroups creating step is like this:
1. Setup a cgroup (now it has no process in it)
2. Write the pid of this process to cgroup and execve the command immediately afterward
I guess there is no over-measuring or under-measuring during this process, but I'm not sure.
Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> 于2024年6月16日周日 21:10写道：
_______________________________________________HiI think the key here is : when exactly cgroup is created for your program?On Sun, Jun 16, 2024, 15:53 Heran Yang <herany1999@xxxxxxxxx> 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, whichis ~1000KiB. I guess that it has some connection with max_rss inheriting, but I'm not sure about that. Do you haveany 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, whichis ~1000KiB. I guess that it has some connection with max_rss inheriting, but I'm not sure about that. Do you haveany 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
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
