John Summerfield:
>>>>>>>>>>>>>
> 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).
I did mean to comment on this too;-)
Linux's caching for single-OS machines isn't so wonderful either. I'm run a
postgresql database load a few times by way of a benchmark/test, and a
result is
that my 256 Mbytes of RAM gets absolutely full of database stuff.
Then my desktop (KDE or GNOME) gets very slow indeed for a while until the
cache
gets recharged with stuff from /usr.
<<<<<<<<<<<<<<<
But the /usr stuff that gets re-loaded are executables and data
(impure)
segments of the code to be run. Unless the KDE stuff is all
scripting
(yeah, like it's all done w/ tcl/TK, smoke and mirrors) then it's
going
to consist of computational pages rather than persistent storage
(which
is just a fancy AIX name for data that's reflected on disk; the code
segment of an executable gets to be both, in a way).
It can be argued that the memory allocation mechanism needs to be
looked
at to allow a memory request to have it's own priority level, just
like
each process has a priority within the scheduler. Hmmmm...
Doing this would benefit _all_ platforms.
--------------------
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
