The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Michael Kjörling" <michael@kjorling.se>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view
Date: Fri, 9 Jul 2021 20:14:25 +0000	[thread overview]
Message-ID: <9732faa4-55cf-44c4-9bdc-47c4c9b40c3f@localhost> (raw)
In-Reply-To: <YOdyjcVCL5TS3VBg@mit.edu>

On 8 Jul 2021 17:47 -0400, from tytso@mit.edu (Theodore Ts'o):
>> 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.

You may very well be correct. That would, however, seem to me to make
it _correct_, but still not necessarily _meaningful_ for trying to
determine the amount of memory used by a _specific_ process; and
similarly for the RSS.


>> 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:

On this, I believe I must stand corrected.

For my previous post, I checked the man page for ps, and noted that
RSS and VSZ are both reported in units of 1 KiB. For an attempt just
now, the ps output is similarly:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
michael  29890 51.8  0.7 2728696 255456 tty2   Sl+  21:46   0:06 firefox-esr
michael  29942  4.7  0.3 2415008 106448 tty2   Sl+  21:46   0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isF
michael  29994 38.3  0.7 34043160 240612 tty2  Sl+  21:46   0:04 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isF
michael  30168  3.2  0.2 2400636 72992 tty2    Sl+  21:46   0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isF

On my system, unless I need to get a different calculator, 0.7% of
memory is either 229 ± <16 or 688 ± <49 MiB, depending on whether it
counts only RAM or also includes swap space.

The 249 MiB RSS of the main process also much more closely matches the
difference that was reported by `free` in my previous experiment.
Oddly, when trying the same thing again now, the difference as
reported by `free` is 423 MiB, so I'm not quite sure what's going on
there, but at least all of those numbers are considerably more
_plausible_, both in isolation and in relation to other relevant
measurements.

I'm honestly not sure how I went from the `ps` output (which wasn't
particularly dissimilar from the above, though of course I don't know
what the exact numbers were since I didn't record them) and the unit
of measurement being KiB, to going from KiB straight to GiB.


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

This is definitely a point on which I agree, and which I tried to
point out with the mention of shared libraries in my previous post.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


  reply	other threads:[~2021-07-09 20:24 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                           ` [TUHS] [tuhs] The Unix shell: a 50-year view Theodore Ts'o
2021-07-09 20:14                             ` Michael Kjörling [this message]
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=9732faa4-55cf-44c4-9bdc-47c4c9b40c3f@localhost \
    --to=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).