> > 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.
Shared libraries get paged in too, just like an executable, so
they don't live in the buffer cache. There's been some talk
about making such segments shared between VMs but (IMHO) that
will take a huge quantity of code which (again, IMHO) Linus
(_and_ all his lieutenants) are unlikely to accept, considering
how specialized it is (and how inapplicable to all other
environments).
> > 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.
It's a non-trivial amount of code, it's exceptionally specialized,
it's not a new "device driver" so it's not well compartmented...
I've done _some_ kernel and device driver work, admittedly not
much on Linux, but LynxOS (almost 10 years ago) and freeBSD
(about 5) so I can appreciate the size of this job. It's a
serious amount of work that'll have to be spread pretty far and
wide and "talking" to VM's CP pretty often. This is not good
for encapsulation.
> 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
I'm not sure but I'd suspect that page steals of code segment
pages may be counted as page outs, even if they're just page
expires. I'll have to look at the relevant counters within
the kernel source and see where they get incremented, just to
be sure.
AIX is much weirder than Linux when it comes to the Virtual
Memory Manager since the VMM does _all_ of the work managing
disk I/O (files/etc get "mapped" as memory segments and reads
are handled as page faults. Hence, AIX == AInt uniX, at least
deep inside) so some of the number have to be carefully
interpreted.
--
John R. Campbell Speaker to Machines [EMAIL PROTECTED]
- As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!
Disclaimer: All opinions expressed above are those of John R. Campbell
alone and are seriously unlikely to reflect the opinions of
his employer(s) or lackeys thereof. Anyone who says
differently is itching for a fight!
