How to accout max_rss precisely

Valdis Kl=?utf-8?Q?=c4=93?=tnieks valdis.kletnieks at vt.edu
Mon Jun 3 13:44:31 EDT 2024


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__ at 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 at 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....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20240603/614dfcbd/attachment.sig>


More information about the Kernelnewbies mailing list