From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31745 invoked from network); 7 Jul 2021 20:59:01 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2021 20:59:01 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 41F0D9CA41; Thu, 8 Jul 2021 06:58:56 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 387159C862; Thu, 8 Jul 2021 06:58:29 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id D47319C862; Thu, 8 Jul 2021 06:58:25 +1000 (AEST) X-Greylist: delayed 447 seconds by postgrey-1.36 at minnie.tuhs.org; Thu, 08 Jul 2021 06:58:24 AEST Received: from pio-pvt-msa3.bahnhof.se (pio-pvt-msa3.bahnhof.se [79.136.2.42]) by minnie.tuhs.org (Postfix) with ESMTPS id AC3839C854 for ; Thu, 8 Jul 2021 06:58:24 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTP id E966E3F61A for ; Wed, 7 Jul 2021 22:50:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from pio-pvt-msa3.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa3.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O91OE9gTHAz for ; Wed, 7 Jul 2021 22:50:53 +0200 (CEST) Received: by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTPA id C213A3F5FF for ; Wed, 7 Jul 2021 22:50:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTPS id D96BD2E0145 for ; Wed, 7 Jul 2021 22:50:52 +0200 (CEST) Date: Wed, 7 Jul 2021 20:50:51 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: tuhs@minnie.tuhs.org Message-ID: <6b736f82-97ed-4e51-9652-e672be4e2c66@localhost> References: <396911b232bae5938068a14fe0f7181e@firemail.de> <20210704004757.GB24671@tau1.ceti.pl> <20210705071450.GA12885@tau1.ceti.pl> <20210706231659.GA13225@tau1.ceti.pl> <20210707183222.GA9897@tau1.ceti.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210707183222.GA9897@tau1.ceti.pl> Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 7 Jul 2021 20:32 +0200, from rtomek@ceti.pl (Tomasz Rola): > An excerpt from my ps: > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > > xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 firefox-esr 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. 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. It is downright _impossible_ that Firefox could actually be using that amount of volatile memory, because my system has "only" 32 GB RAM + 64 GB swap. The root file system, which on my system also holds the likes of /usr/{bin,lib}, totals 29701 MB used according to `df -m`, plus ~ totals 22550 MB, so even if Firefox read _all_ of that into memory it still wouldn't be anywhere _close_ to the reported RSS value, falling short by about a factor 7x (and Firefox has no reason to even look at much of what's there, like the 2.5 GB in /usr/share/games/flightgear). While that Firefox instance was running, I ran `free -m`, which reported 250 MB swap used (65285 MB free) and 26008 MB "memory available". Very soon after closing Firefox (and soon enough to try to ensure that nothing else major changed), I ran `free -m` again, which then reported the same 250 MB swap used and a slightly larger 26298 MB memory available; a difference of 290 MB between when Firefox was running and when it was not. That's a _factor almost 2300x_ difference between the reported RSS, and the amount of memory that was actually freed up by closing the browser. The same experiment done with a brand-new browser profile gave a total RSS of 751 GB for Firefox's processes combined, while free reports a difference of 321 MB between running and not-running. That's within striking distance of a factor 2400x difference. Does this mean that software bloat isn't an issue? I would argue that it does not. Does it mean that Firefox can't have, say, memory leaks, causing it to over time have more memory allocated than it actually uses? It does not; and in fact I believe that's something that has been worked on over the years. But I think it's worth trying to be honest about all this, and at least _try_ to not compare apples to stars just because both resemble oblate spheroids and exert gravitational influence. On modern systems, with everything from shared libraries to memory-mapped I/O to routine use of memory overcommitting, the resident set size is clearly a poor indicator of the actual amount of memory actively used by a complex process. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”