aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) (08/28/89)
(1) Can we move the thrashing and working set discussion to comp.os.research
or some other, similar, newsgroup. (I know, I made the mistake of
responding to it as well).
(2) That said, I'll respond to a post in the thrashing discussion.
However, I believe it is pertinent to comp.arch:
>Many classic VM algorithms (such as Working Set) do consider processes
>and degree of thrashing, etc., but these algorithms seem to be little
>used in recently designed o.s.'es. [Since this is comp.arch, I will
>note in passing that is may be partly due to brain-dead VM hardware,
>such as the VAX, which doesn't even have a reference bit.]
May I suggest reading "Supporting Reference and Dirty Bits in SPUR's
Virtual Address Cache", DA Wood and RH Katz, _Proc_16th_Ann_Symp_ -
_Comp_Arch_, 1989.
They suggest that hardware support for reference and dirty bits
is not-so-necessary in modern machines that page infrequently, and may
even be a performance loss; they point out that there are software
techniques for implementing these bits, and some hardware/software
compromises.
I have learned from my own experience that hardware table walking
and modifiable bits in the PTEs can have a high cost (table
walking because it requires an interlock between the hardware
process that walks the tables, and the software process that
modifies them (for pageins, etc.): this interlock is hardly
ever made explicit, and can result in all table walks being
treated as RMC cycles on the bus) (modifiable bits in the PTEs
for much the same reason).
One of my favorite conversational gambits recently has been to
observe that hardware has been providing software with high
functionality, small grain virtual memory for maybe 20 years;
software has done little to take advantage of this functionality
in all this time; and hardware, doing a cost/benefit analysis, is
now beginning to reduce the functionality and increase the
granularity of virtual memory, just as software, such as MACH, is
finally beginning to take advantage of virtual memory.
(3) Finally, a question: has anyone encountered a VM system that could
have a writable, but not readable, page?
I've come across a configuration where the memory is too slow to
read from, but buffering makes me care less how long it takes to write;
I'd like to fault on read references so that I can move it closer.
--
Andy "Krazy" Glew, Motorola MCD, aglew@urbana.mcd.mot.com
1101 E. University, Urbana, IL 61801, USA. {uunet!,}uiucuxc!udc!aglew
My opinions are my own; I indicate my company only so that the reader
may account for any possible bias I may have towards our products.