Re: Paging file

Huh?

And this is circumvented on other systems?

Anyway, I believe there's a flaw in your thinking.  If the data needs to be
rewritten, there's no guarantee that it'll go back to "the same place" on
the disk.  In fact, if I understand it correctly (and I thought I did), it
likely won't go back to the same spot.  If it hasn't changed, it won't be
rewritten.  If it has changed, it's subject to standard writing rules,
again as I understand it.

HTH
Dennis





James Rich <james@eaerich.com>@midrange.com on 10/29/2002 12:13:47 PM

Please respond to midrange-l@midrange.com

Sent by:    midrange-l-admin@midrange.com


To:    midrange-l@midrange.com
cc:
Subject:    Re: Paging file


On Tue, 29 Oct 2002, Hans Boldt wrote:

> others. But since all processes in an SLS architecture share the
> same (humongous) virtual address space, you need some means of
> ensuring that a process really is allowed to access a particular
> region of store. That puts more overhead on securing memory
> accesses, which requires substantial capabilities in the CPU itself.
> It also meant 16 byte pointers, which can increase memory
> requirements. If you remember back to the early days of the S/38, it
> had significant performance problems, which adversely affected the
> way system programming was done. (There *were* some very good

In addition to this it seems to me that there is another performance
problem with single level store.  I don't know this for sure but it seems
right.  If an object in main memory needs to be pushed back to disk
because memory is low, it is written back to its original location on
disk.  Then when it is retrieved back into main memory it is read again
from that spot on the disk.  This is ineffecient use of disk, as these
reads/writes will be all over the place instead of in a closely clustered
area of disk.

James Rich