<div dir="ltr">Hi!<div><br></div><div>I do this test leverage systemd-run. The command likes:</div><div><br></div><div>systemd-run --user --unit test --wait ./a</div><div><br></div><div>Though there are some accounting bugs in systemd-run (check PR #33258), the accounting value is aligned</div><div>with cgroups. The cgroups creating step is like this:</div><div><br></div><div>1. Setup a cgroup (now it has no process in it)</div><div>2. Write the pid of this process to cgroup and execve the command immediately afterward</div><div><br></div><div>I guess there is no over-measuring or under-measuring during this process, but I'm not sure.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mulyadi Santosa <<a href="mailto:mulyadi.santosa@gmail.com">mulyadi.santosa@gmail.com</a>> 于2024年6月16日周日 21:10写道：<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="auto"><div>Hi</div><div dir="auto"><br></div><div dir="auto">I think the key here is : when exactly cgroup is created for your program?</div><div dir="auto"><br></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sun, Jun 16, 2024, 15:53 Heran Yang <<a href="mailto:herany1999@gmail.com" target="_blank">herany1999@gmail.com</a>> wrote:<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">杨贺然 <<a href="mailto:herany1999@gmail.com" rel="noreferrer" target="_blank">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" rel="noreferrer" 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>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" rel="noreferrer" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div>