Doesn't the first model lead Linux to do it's own caching of large amounts of files causing excessive paging when it should be doing I/O operations?
-----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Coffin Michael C Sent: Thursday, August 12, 2004 1:58 PM To: [EMAIL PROTECTED] Subject: Re: VDSK Swap - allocation size? Hi Adam, So given two memory models: 1. Linux virtual machine has enough virtual storage to run all programs it needs to without swapping, tiny swap space. 2. Linux virtual machine has small virtual storage and swaps often, large swap space. Wouldn't CP be a better pager in Model #1 than having CP page the (smaller) VM in #2 and having Linux do it's own swapping as well? I admit, I haven't run my own benchmarks - but I thought model #1 was the way to go (that and it makes sense to me to have CP do what he does best, page virtual machines). Michael Coffin, VM Systems Programmer Internal Revenue Service - Room 6527 1111 Constitution Avenue, N.W. Washington, D.C. 20224 Voice: (202) 927-4188 FAX: (202) 622-6726 [EMAIL PROTECTED] -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: Thursday, August 12, 2004 1:43 PM To: [EMAIL PROTECTED] Subject: Re: VDSK Swap - allocation size? On Aug 12, 2004, at 12:33 PM, Coffin Michael C wrote: > Hi David, > > I've always been under the impression that the best configuration for > Linux/390 guest swap is to make the virtual machine storage as large > as it SHOULD need under normal operating conditions, and give the > guest practically NO swap. Since Linux wants to "exploit" his memory > and swap > space as if he were a "stand alone" machine - the intent is to not > give him > more than he absolutely needs to prevent him from doing "clever > things" with > it, no? I disagree. I would make virtual storage only as large as necessary to accommodate a reasonable workload with very little memory in use by buffers and cache. Then enough high-priority swap-on-VDISK to handle usual (workload-specific) fluctuations in memory usage without having to go to real DASD, and then enough low-priority swap on real DASD to handle extraordinary, infrequent memory spikes (if you need those handled, rather than just having the application get a failure when it tries to allocate however hoggishly much it asked for). > Response time to all remains excellent (well, except for 'piggy' > things like Java on Linux/390 - which we've pretty much given up on). It's probably not mostly Java's fault. It's possible to write reasonably efficient code in Java. It's just that no one who uses Java *does*, because the language encourages you to use superfluous classes for everything (the language culture does too--don't underestimate the effect of linguistic culture in programming), and since it's garbage-collected you don't even need to think about memory usage when you're working. I'm not a big fan of malloc() and free()--it's really easy to make mistakes when the programmer has to manually manage memory allocation--but at least making it the application developer's *job* means that your developers can't just sweep the problem under someone else's rug, which is what Java encourages. Adam ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
