× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Wed, 24 Nov 2004 CWilt@xxxxxxxxxxxx wrote:

"Single-level store is not about a large address space; it's about sharing."

"It may seem obvious to some that every server designed to support a
multi-user, multi-application environment should use an addressing model
designed for sharing.  As I stated earlier, this is a foreign concept to
hardware and operating system designers."

The above implies that only single level store (SLS) systems can share memory between applications and users. That is not true.


Further, it may not be that such a system "should" use an addressing model designed for sharing (whatever that means). Consider a system with several LPARs or system partitions. Certainly memory should not be shared across unless you specifically want to. There must be a wall of separation. Or to stick within on logical system, consider a system that implements military style security protections such as SELinux. Part of the design mandate is that memory not be shared.

So for these two reasons I think we can conclude that the premise that "every server designed to support a multi-user, multi-application environment should use an addressing model designed for sharing (which we suppose is SLS)" is false.

"Virtual memory evolved to support time-sharing by giving each user a
separate address space.  One users memory space was isolated from another
users, thereby providing a degree of protection between them."

"Worse yet, the designers of these time-sharing systems decided to keep the
file system outside virtual memory. They created two places to store data
and programs: the virtual memory and the file system.  With this design, the
data and programs can be used or changed only when they are in virtual
memory.  This means anything in the file system must be moved into virtual
memory before it can be used or changed."

The second paragraph tries to paint the "degree of protection" described in the first paragraph as a bad thing. But then it goes on without addressing why that protection is bad. Instead it talks about some possible flaws in implementation of memory systems but leaves untouched the design purpose of the protection between users. This is a flawed argument.


"A simple, familiar example for this process is using a word processor on a
PC.  We first open the file, which contains the document we want to use, and
we watch the hard disk light blink as the document is read into memory.
Actually, it is first being read into our virtual memory and then part of
the document is read into memory.  When we originally configured our PC
operating system, we told it how much disk space should be reserved for
virtual memory.  In the PC world, this is called the application swap file.
As we scroll through the document, we notice the hard drive light again
blinking.  As needed, new parts of the document are being read into memory
from this reserved space.

Parts of this are wrong and parts we'll come back to later.

The sentence, "Actually, it is first being read into our virtual memory and then part of the document is read into memory" is wrong (or at least it is on the only non-SLS system I am familiar with: linux). When the disk is read it is always copied into RAM first. If and only if there is not enough space in RAM to hold the data are some parts of RAM paged out to disk. Those parts are chosen carefully in order minimize the chances that any process will want to access them anytime in the near future. The idea that a file on disk is first copied to swap and then to RAM is completely false.

        The act of opening the file has created a second copy of our
document.  The original copy of the document still exists unchanged on our
hard drive.  The second copy is in the disk space reserved for virtual
memory. ... There are actually three copies of some parts of the document,
if we count the copy in memory."

This last sentence is also wrong. The whole point of virtual memory is to have a place to put things when you have run out of space in RAM. Thus things are written to swap *when they no longer fit in RAM*, i.e. the stuff in swap is not in RAM any longer. If it were, they why swap it out?


[Single-Level Virtual Memory]
"The programmer in the virtual memory implementation just described sees and
managers two levels of storage; the file system and virtual memory are
separate.  This two-level store also creates overhead in the system.
Opening a file causes a disk write to the swap area and closing a file
requires a disk write back to the permanent location.  An alternative
approach is to have only one copy of the file.

Again, opening a file does not cause a disk write to the swap area unless the memory required by a process exceeds the amount available in RAM. And then it is highly unlikely that the process reading the file will have any of its parts swapped, since that is the process that the system is making room for!


Further, simple reasoning leads to the conclusion that even a SLS system must have two copies of disk data read into memory: that which is on the disk and that which is in memory. If it were not so, then that would mean then when something is read into RAM, it would no longer exist on disk! Removing data from disk to put it into RAM is surely not what a SLS system does. Thus there are two copies.

        Not having two separate copies means we don't need to reserve disk
space for a swap file.  With this approach, the entire file system becomes
part of virtual memory."

"The open and close operations no longer must physically copy the entire
file from its permanent location on the disk.  Only the portion (or record)
you're reading or working on is copied to a memory buffer.  We often
describe this by saying files are always used "in place," thereby improving
overall system performance."

Now we return to the word processor example from above. The above paragraph says, "The open and close operations no longer must physically copy the entire file from its permanent location on the disk. Only the portion (or record) you're reading or working on is copied to a memory buffer." The implication is that non-SLS system do copy the entire file into RAM. But the word processor example above said, "As we scroll through the document, we notice the hard drive light again blinking. As needed, new parts of the document are being read into memory from this reserved space." We already showed that the document is not read from swap. Thus this reading of new parts of the file are disk reads from the location of where the file is stored on disk, just like we expect. This is in direct conflict with the premise of the above paragraph the non-SLS systems read the entire file into RAM at once instead of piece by piece as needed. The quoted article contradicts itself.


"As with a two-level virtual memory, the memory is still used as a buffer.
Processors can operate directly only on data in memory, not on the disk.
The difference with only one level is that memory is now a cache for all the
disk storage, rather than for only a reserved area on the disk.  Also, when
one user makes a change to a file, the change is instantly available to any
other user who shares the file."

Memory [RAM] can only be a cache for all the disk storage if the amount of RAM equals the amount of disk, regardless of whether a system uses SLS or not. Any time the RAM is less than the amount of disk then the RAM cannot possibly cache all the disk - it simply won't fit.


I know the article quoted is an IBM document and I'm no uber-hacker. But the article simply doesn't stand on its own two feet.

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.