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.sant...@gmail.com> 于2024年6月16日周日 21:10写道：
> 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
>
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
