The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Michael Kjörling" <michael@kjorling.se>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view
Date: Thu, 8 Jul 2021 17:47:57 -0400	[thread overview]
Message-ID: <YOdyjcVCL5TS3VBg@mit.edu> (raw)
In-Reply-To: <6b736f82-97ed-4e51-9652-e672be4e2c66@localhost>

On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote:
> 
> I'm going to stick my neck out here by saying that the VSZ and RSS
> values reported by ps, at least for Firefox, are largely meaningless.

No, VSZ is correct, but it's confusing since it includes things that
you might not expect.  VSZ includes *all* virtual memory space
consumed by a process.

For example, consider this simple program:

main(int argc, char **argv)
{
	printf("Hello, world\n");
	sleep(10);
	return 0;
}

It uses shared libraries:

% ldd /tmp/hello
        linux-vdso.so.1 (0x00007fff20bff000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd8caad9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd8cacca000)

If you run the program the ps listing looks like this:

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
tytso    4060239  0.0  0.0   2300   512 pts/2    T    17:01   0:00 /tmp/hello

If you look at /proc/4060239/maps, you'll memory map for the process.

5559e8e7d000-5559e8e7e000 r--p 00000000 00:25 260006                     /tmp/hello
5559e8e7e000-5559e8e7f000 r-xp 00001000 00:25 260006                     /tmp/hello
5559e8e7f000-5559e8e80000 r--p 00002000 00:25 260006                     /tmp/hello
5559e8e80000-5559e8e81000 r--p 00002000 00:25 260006                     /tmp/hello
5559e8e81000-5559e8e82000 rw-p 00003000 00:25 260006                     /tmp/hello
5559ea383000-5559ea3a4000 rw-p 00000000 00:00 0                          [heap]
7f8419a44000-7f8419a69000 r--p 00000000 fc:00 10763398                   /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f8419a69000-7f8419bb4000 r-xp 00025000 fc:00 10763398                   /usr/lib/x86_64-linux-gnu/libc-2.31.so
			  ...

If you add the sum total of all of the VM regions, i.e.:

(0x5559e8e7e000 - 0x5559e8e7d000) +
(0x5559e8e7f000 - 0x5559e8e7e000) +
(0x5559e8e80000 - 0x5559e8e7f000) +
	...

(ignore the last vsyscall region, since that's a kernel page mapped
into all processes)   You'll get the 2300k of the VSZ.

If the process mmap's in a large 2GB file, the VSZ will go up by 2GB,
even if none of the file is paged in.  Or if you mmap in 2MB of
anonymous memory backed by the zero page for the heap, the VSZ will go
up by 2MB.  

> I started my usual Firefox instance, which has a handful of plugins,
> about a metric gazillion bookmarks, and has been my main web browser
> profile for years (so it probably has collected some crud over time).
> `ps auxw` reported that process as having a total RSS of a whopping
> 374 GB.

I don't think that's right.  Are you sure it's not 374MB?  I started
firefox-esr on my Debian machine, and the PS output is:

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
tytso    4063201  5.8  1.0 3027868 357248 pts/2  Sl   17:38   0:07 firefox-esr
tytso    4063274  0.5  0.3 2446608 105620 pts/2  Sl   17:38   0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isF
tytso    4063317  0.8  0.3 2457032 124200 pts/2  Sl   17:38   0:01 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isF
tytso    4063341  2.9  0.8 2623896 282420 pts/2  Sl   17:38   0:03 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isF

357248k is 343MB.  Maybe you were adding up the RSS's for all of the
processes?  That's misleading because if a physical 4k page is shared
across multiple process, that 4k page will be accounted in each of the
processes's RSS --- even if that process hasn't actually *used* that
particular page.  So for example, the hello world program had a 512k RSS:

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
tytso    4060239  0.0  0.0   2300   512 pts/2    T    17:01   0:00 /tmp/hello

That's not because the hello world program actually used half a
megabyte worth of the C library; but rather, almost half a megabyte of
the C library has been paged in to support all of the processes
currently running in the system.  It also follows that every process
using shared library is going to have an RSS which is at least 512k.

Cheers,

					- Ted

  parent reply	other threads:[~2021-07-08 21:49 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02 21:24 Nelson H. F. Beebe
2021-07-02 21:36 ` Larry McVoy
2021-07-02 21:56   ` Henry Bent
2021-07-02 23:12     ` Steve Nickolas
2021-07-02 23:49       ` Steffen Nurpmeso
2021-07-03 13:34         ` Steffen Nurpmeso
2021-07-03 13:56           ` Richard Salz
2021-07-03 12:04       ` Thomas Paulsen
2021-07-03 13:20         ` Dan Cross
2021-07-03 17:37           ` Theodore Ts'o
2021-07-03 17:57             ` Warner Losh
2021-07-03 18:10               ` Theodore Ts'o
2021-07-03 20:02                 ` Dan Cross
2021-07-04  0:47           ` Tomasz Rola
2021-07-04  4:36             ` Larry McVoy
2021-07-04 14:56               ` Dan Cross
2021-07-04 16:07               ` Theodore Ts'o
2021-07-04 20:10               ` David Barto
2021-07-05  0:25                 ` Larry McVoy
2021-07-05  1:23                 ` John Cowan
2021-07-04 12:48             ` Dan Cross
2021-07-05  7:14               ` Tomasz Rola
2021-07-05 16:26                 ` John Cowan
2021-07-06 23:17                   ` Tomasz Rola
2021-07-06 23:47                     ` Steve Nickolas
2021-07-06 23:49                       ` Warner Losh
2021-07-06 23:48                     ` John Cowan
2021-07-07  0:46                     ` Theodore Ts'o
2021-07-07  0:58                       ` George Michaelson
2021-07-07  2:48                         ` Larry McVoy
2021-07-07 18:32                       ` Tomasz Rola
2021-07-07 20:50                         ` Michael Kjörling
2021-07-08  6:46                           ` [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view) Tomasz Rola
2021-07-08 13:59                             ` Derek Fawcus
2021-07-08 19:25                               ` Steffen Nurpmeso
2021-07-08 19:37                                 ` Steffen Nurpmeso
2021-07-08 20:40                                 ` Steffen Nurpmeso
2021-07-08 22:23                             ` Kevin Bowling
2021-07-08 21:47                           ` Theodore Ts'o [this message]
2021-07-09 20:14                             ` [TUHS] [tuhs] The Unix shell: a 50-year view Michael Kjörling
2021-07-07 13:54                     ` Tony Finch
2021-07-06 16:05                 ` Clem Cole
2021-07-09 22:19                   ` Tomasz Rola
2021-07-04 20:10           ` Tony Finch
2021-07-05  3:59             ` Theodore Ts'o
2021-07-05 15:08               ` Steffen Nurpmeso
2021-07-05  3:52           ` Bakul Shah
2021-07-04 18:17     ` John Dow via TUHS
2021-07-04 19:46       ` Clem Cole
2021-07-05  1:33         ` Noel Hunt
2021-07-05  2:38           ` Clem Cole
2021-07-05  2:51             ` Warner Losh
2021-07-05  3:03               ` Clem Cole
2021-07-05  3:01             ` Clem Cole
2021-07-05  5:22             ` Noel Hunt
2021-07-06  5:10           ` Nevin Liber
2021-07-06 13:30             ` Clem Cole
2021-07-06 16:23               ` Theodore Ts'o
2021-07-07  1:57                 ` Dan Cross
2021-07-07  2:52                   ` Larry McVoy
2021-07-07  5:19                     ` Andrew Warkentin
2021-07-07 18:28                   ` Jon Steinhart
2021-07-10 11:51                     ` [TUHS] " Ralph Corderoy
2021-07-10 13:54                       ` Henry Bent
2021-07-10 14:12                         ` Ralph Corderoy
2021-07-10 16:57                           ` [TUHS] Death by bug [formerly The Unix shell: a 50-year view] Jon Steinhart
2021-07-11  8:53                             ` [TUHS] Death by bug Ralph Corderoy
2021-07-11  9:04                               ` arnold
2021-07-12  1:42                                 ` Theodore Y. Ts'o
2021-07-12  2:57                                   ` Jon Steinhart
2021-07-12  6:39                                   ` arnold
2021-07-12  9:56                                   ` Ralph Corderoy
2021-07-11 16:10                               ` Jon Steinhart
2021-07-12 10:37                                 ` Ralph Corderoy
2021-07-06 13:40             ` [TUHS] [tuhs] The Unix shell: a 50-year view John Cowan
2021-07-06 14:12             ` Chet Ramey
2021-07-07  0:53               ` Nevin Liber
2021-07-07 13:08                 ` Chet Ramey
2021-07-07 15:15                   ` Richard Salz
2021-07-03  0:09   ` Andrew Warkentin
2021-07-03 15:49   ` Andy Kosela
2021-07-04 23:24     ` [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year view) Derek Fawcus
2021-07-04 23:50       ` Nemo Nusquam
2021-07-05  0:15         ` Dan Stromberg
2021-07-05  0:21       ` Larry McVoy
2021-07-05  2:36         ` John Cowan
2021-07-05  2:59           ` Richard Salz
2021-07-05  3:47           ` Larry McVoy
2021-07-05  4:02             ` Dan Stromberg
2021-07-05 13:45               ` Steffen Nurpmeso
2021-07-05 20:15                 ` Dan Stromberg
2021-07-05 21:05                   ` Larry McVoy
2021-07-05 21:29                   ` Clem Cole
2021-07-05 22:22                     ` Brantley Coile
2021-07-06  4:35                     ` Dan Stromberg
2021-07-06  4:44                       ` Warner Losh
2021-07-06  5:58                       ` Rico Pajarola
2021-07-06 13:05                       ` Clem Cole
2021-07-05 12:11         ` Thomas Paulsen
2021-07-05  4:08       ` Dan Stromberg
2021-07-05  4:23         ` George Michaelson
2021-07-05 14:43           ` Larry McVoy
2021-07-05 15:17             ` Steffen Nurpmeso
2021-07-05 15:36               ` Steffen Nurpmeso
2021-07-05 15:53       ` Mike Markowski
2021-07-05 16:39       ` Warner Losh
2021-07-05 19:02         ` Clem Cole
2021-07-02 22:27 ` [TUHS] [tuhs] The Unix shell: a 50-year view Chet Ramey
2021-07-02 23:09 ` Steve Nickolas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YOdyjcVCL5TS3VBg@mit.edu \
    --to=tytso@mit.edu \
    --cc=michael@kjorling.se \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).