> I hate the lack of sensible quoting w/i Bloated Notes. > > >>>>>>>>>>> > I thought we were talking about buffers for files, not storage allocated to > programs during use (and that's what stack, bss are). > > Everything in /usr is supposed to be mountable r/o. > > > However, Linux doesn't know that VM might be caching it, so Linux caches it > too > and this leads to increased storage use by Linux as seen by VM. So, to > reduce > this caching, reduce the storage allocated to the Linux instance. > <<<<<<<<<<< > > It took me a surprising amount of time to realize that /usr doesn't > retain any large quantities of data that would end up residing in a > buffer cache- R/O data is of very limited utility. I don't think > we're likely to be overrun by people calling up the same man page > across all of the systems.
Binaries including shared libraries are extremely likely to be used on all guests. Take glibc for starters. > The other question deals with paging/swapping. As far as I can figure it, > paging > in Linux/Unix isn't what it is in MVS, and I've never discovered just what > the > correspondences is. So, I use the terms swapping and paging as I did in my > MVS > days. > > There was some discussion about this quite a while ago. As I recall, the > best > solution offered is to modify Linux so it recognises it's running in a VM > environment and to discuss paging operations with VM. I think the feeling > was > that VM also needed to have some changes made as the way it discusses these > matters with other guests isn't ideal for Linux. > > I imagine that the IBM folk are beavering away at fixing this up properly > as I > type - I think it's working hours in ibm.de;-) > <<<<<<<<<<<< > > IIRC the commentary here on the list was that some folks are working > at getting Linux better at peering w/ VM, which, IMHO, is a non- > starter. I don't see Linus admitting code like that into the > mainline I don't see why not (but as I already hinted, I'm not a kernel developer). It's no different in kind than the PC BIOS and the kernel does use some of that. > kernel. A more generic approach (like tuning the disk buffer cache > mechanism to throttle new buffer requests) would be best, but that > needs to be done in such a way that a code segment won't get paged > out to make room for a disk buffer; Only other disk buffers should > be eligible for flushing and reallocation. > > (BTW, code segments don't get written out to the paging space; They > get dropped because they'll just get re-loaded from the executable > file image when the page faults again. As if anyone on this list > didn't > already know or have an inkling of how this works.) There IS something that seems very odd about paging. [summer@dugite summer]$ procinfo Linux 2.4.9-31 ([EMAIL PROTECTED]) (gcc 2.96 20000731 ) #1 Tue Feb 26 06:25:35 EST 2002 1CPU [dugite] Memory: Total Used Free Shared Buffers Cached Mem: 118276 111356 6920 56 18244 48452 Swap: 393200 79504 313696 Bootup: Fri Mar 22 21:58:04 2002 Load average: 0.00 0.00 0.00 1/119 3343 user : 17:39:54.36 2.1% page in :153050675 disk 1: 1087873r 634957w nice : 0:40:06.56 0.1% page out:109710024 disk 2: 3023r 0w system: 19:29:41.91 2.4% swap in : 906529 disk 3: 3196130r 2349159w idle : 32d 19:35:23.04 95.4% swap out: 238519 disk 4: 3304476r 1724676w uptime: 34d 9:25:05.85 context :495785638 irq 0: 297150587 timer irq 7: 40809857 parport0 irq 1: 9426 keyboard irq 8: 121 rtc irq 2: 0 cascade [4] irq 10: 14 aic7xxx irq 3: 4 serial irq 11: 124166017 eth0 irq 4: 770936353 serial irq 14: 1720315 ide0 irq 6: 2 irq 15: 10557958 ide1 [summer@dugite summer]$ See those "page out" numbers. I get page out numbers > 0 even if I run without swap -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. ============================== If you don't like being told you're wrong, be right!
