>>>>>> "Post, Mark K" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 04/25/2002 11:37:05 AM
Please respond to Linux on 390 Port <[EMAIL PROTECTED]> Sent by: Linux on 390 Port <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: LinuxWorld Article series Yes, and it also assumes that the system administrator hasn't taken steps to minimize this. Such as, reducing the amount of virtual storage allocated to the instance, and adding a v-disk as a paging device. Putting "pressure" on the storage use algorithms will reduce the amount used for buffering and cache, so only frequently used things will remain in storage. Mark Post -----Original Message----- From: James Melin [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 25, 2002 11:10 AM To: [EMAIL PROTECTED] Subject: Re: LinuxWorld Article series This assumes that every Linux image is going to be using the same disk, does it not? <<<<<<<<<<<< I've thought that it should work the OTHER way once a mechanism to throttle buffer allocation has been cooked up; You'd best depend upon VM to handle paging your system (to avoid double-paging) and remove the paging space ("swap" partition) from Linux entirely. So you could have a very large "virtual" instance but it wouldn't have any "local" paging space, depending instead upon VM to manage the paging of the instance. Coupled with a buffer-leashing (we can hope it's tunable via a /proc entry or some such) this'd make each instance more likely to "play well with others". As for replicated buffers in the cache, yes, I've seen the cookbooks recommend building a single instance and then providing r/o access to other instances for the /usr filesystem, so this would be a concern. While reducing the replication of files is a laudable goal we're still stuck w/ replicated buffers. The only real advantage is with executables, since page misses in the code segments will just pull it in from the file itself (computational pages) and data (stack, bss) segments will be "unique" to each instance's processes anyway. Replicated buffers for persistent storage (i.e. data files) is less of a problem since data will vary from instance to instance. So it looks like a problem where you're replicating the contents of "shared" mdisk files across the instances but this replication will not be in the buffer cache but in the code segments of the programs running in each instance, and there's not much you can do to reduce this- and it'd add a huge amount of overhead to even _think_ about doing so. If data doesn't vary instance-to-instance there's not much point to having multiple instances, eh? Mind you, I don't have my own root/shell access to an s/390 running linux; I've worked w/ Linux since kernel 0.95 or thereabouts (does anyone out there remember the SLS distro?) and, despite my enthusiasm, I try to maintain some recognition of weaknesses (no one system is ever good at _everything_). Working w/ Xenix (and Unix, early on) one of the tunables was to set the buffer cache size. While the new model of buffer cache management is wonderful for "regular" (non- shared) systems, it's not as good in the VM environment (though we wouldn't want to cripple this feature across the s/390 line, since this feature is not a problem for the bare metal or an LPAR). VM's side effects of virtualization vary a whole lot of "rules" in OS; I don't know if they've ever been codified. Changing the subject slightly, how does Linux run using FBA vs. CKD devices? (It's not like _I_ have the ability to run tests.) -------------------- John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322 "Will Work for CLAIM Codes" IBM Certified: IBM AIX 4.3 System Administration, System Support
