Thanks David Noon for your msg about 512mb Is Ample Right Now, on
Saturday, 10-15-1994!

DN> Well, the way a well-written MVS application deals with this is
DN> that it remaps an already committed page to another part of the disk
DN> file. It saves removing one entry and adding another in the Page
DN> Descriptor Tables (equivalent of LDT's under OS/2) and is generally
DN> considered more efficient than removing the page from commitment and
DN> committing a new page. This is particularly true in a SMP
DN> environment, where the PDT's are cached and any context switch that
DN> also switches from one processor to another causes the cache of
DN> PDT's to be flushed and rebuilt on the other processor. [The page
DN> fault can, itself, precipitate the context switch, since control of
DN> the machine returns to the dispatcher.] 

Make's sense to me. Actually (for me) this whole conversation is kind
of just a waste of brain cells (and I don't have many to waste ;-) as I
don't think I will be dealing with these issues myself any time soon.
But, I hope you are right that the WPOS/2 folks take heed of the issues
that their own company worked out long ago.

And I'm really looking forward (NOT) to seeing how many applications
suddenly fall over when SMP becomes more common on OS/2. My ray
tracing/fractal app that I'm doing is being built to be SMP aware, but
I will not be able to test it out myself because I won't be able to
afford an SMP machine for another year or so. So maybe mine will be one
of the lucky ones, but I doubt it since I understand the issues well
and there aren't that many rules (just to survive anyway, although I'm
sure that there are issues aplenty to maximize CPU utitilization,
etc...)

___
 X KWQ/2 1.2b X If at first you don't succeed, put it out for beta test (KWQ Beta

--- Maximus/2 2.01wb