On Aug 10, 2017, at 2:07 AM, John Hodrien <J.H.Hodrien at leeds.ac.uk> wrote:> > For a well configured desktop that rarely needs to swap, I struggle to see the > load on the SSD as being significant, and yet obviously the performance of an > SSD would make it ideal for swap.I agree. It?s a bad idea to do without swap even if you almost never use it, because today?s bloated apps often have many pages of virtual memory they rarely or never actually touch. You want those pages to get swapped out quickly so that the precious RAM can be used more productively; by the buffer cache, if nothing else. I once used a web application server on a headless VPS that still had GUI libraries linked to its binary because one of the underlying technologies it uses was also used in a GUI app, and it was too difficult to tear all that GUI code out, even if it was never called. Because the VPS technology didn?t support swap, I directly paid the price for those megs of unused (and unusable!) libraries in my monthly VPS rental fees.> Coo, I've never seen a disk actually shrink due to failed sectors. I don't > think I've got an SSD into a worn state yet to see this.Me, neither. I?m pretty sure the spare sector pool?s size isn?t reported to the OS, and the drive isn?t allowed to dip into the sectors it does expose externally for spares. When the spare pool is used up, the drive just starts failing in a way that even SMART can see.
On 8/10/2017 1:12 PM, Warren Young wrote:> It?s a bad idea to do without swap even if you almost never use it, because today?s bloated apps often have many pages of virtual memory they rarely or never actually touch. You want those pages to get swapped out quickly so that the precious RAM can be used more productively; by the buffer cache, if nothing else.most modern virtual memory OS's don't swap out unused pages, instead, they swap IN accessed pages directly from the executable file. only thing written to swap are 'dirty' pages that have been changed since loading. -- john r pierce, recycling bits in santa cruz
On 10/08/17 21:17, John R Pierce wrote:> On 8/10/2017 1:12 PM, Warren Young wrote: >> It?s a bad idea to do without swap even if you almost never use it, >> because today?s bloated apps often have many pages of virtual memory >> they rarely or never actually touch. You want those pages to get >> swapped out quickly so that the precious RAM can be used more >> productively; by the buffer cache, if nothing else. > > most modern virtual memory OS's don't swap out unused pages, instead, > they swap IN accessed pages directly from the executable file. only > thing written to swap are 'dirty' pages that have been changed since > loading. >Modern? They've been doing that since I did my VMS theory 30-odd years ago. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20170810/09e7411d/attachment-0001.sig>
On Aug 10, 2017, at 2:17 PM, John R Pierce <pierce at hogranch.com> wrote:> > On 8/10/2017 1:12 PM, Warren Young wrote: >> You want those pages to get swapped out quickly so that the precious RAM can be used more productively; by the buffer cache, if nothing else. > > most modern virtual memory OS's don't swap out unused pages, instead, they swap IN accessed pages directly from the executable file. only thing written to swap are 'dirty' pages that have been changed since loading.Is that not a distinction without a difference in my case? Let?s say I have a system with 256 MB of free user-space RAM, and I have a binary that happens to be nearly 256 MB on disk, between the main executable and all the libraries it uses. Question: Can my program allocate any dynamic RAM? The OS?s VMM is free to use addresses beyond 0-256 MB, but since we?ve said there is no swap space, everything swapped in must still be assigned a place in physical RAM *somewhere*. Is there a meaningful distinction between: Scenario 1: The application?s first few executable pages are loaded from disk, a few key libraries are loaded, then the application does a dynamic memory allocation, then somehow causes all the rest of the executable pages to be loaded, running the system out of RAM. Scenario 2: The application is entirely loaded into RAM, nearly filling it, then the application attempts a large dynamic memory allocation, causing an OOM error. Regardless of the answer to these questions, I can tell you that switching that web site to a more efficient web application stack allowed us to shrink the VPS from a 256 MB plan, under which it would occasionally crash and require a reboot, to a 64 MB plan, under which the site has been rock-solid. Same VPS provider, same web site content, same user-facing functionality. If I?d had the ability to assign swap space, I probably could have gotten away with a 64 MB VPS plan with the inefficient web technology, too. They gave me plenty of disk space with that plan. (And no, swapon /some-file is no solution here. The VPS technology simply didn?t allow swap space, even from a swap file on one of the system disks. It wasn?t simply an inability to add a swap partition.)