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.
>>>>>>>>>>>
However, this is a problem which I think needs a better long-term solution.
It's
wrong for Linux to allocate lots of cache to /usr (but only when running as
a VM
guest) but right for it to cache /var liberally.
Perhaps a mount option would address this best, but I'm certainly no Kernel
Guru.
<<<<<<<<<<<
The "swap" (paging space) already has a priority flag; Perhaps it
can be borrowed for this? I'll hafta "use the source" to see what
it does now.
Actually, the buffer cache allocation algorithm needs to have a
"cost" associated with each percentage point of free space it
consumes; The rate of expense growth should be tunable, etc. Some
memory allocators used to have such a pricing mechanism to allow the
system to balance out the load.
>>>>>>>>>>>
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
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.)
I *really* need to get a life.
--------------------
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
