Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rex!rouge!ralph!elgamy!elg
From: elg@elgamy.RAIDERNET.COM (Eric Lee Green)
Newsgroups: comp.arch
Subject: Re: Memory hierarchy
Message-ID: <00670398761@elgamy.RAIDERNET.COM>
Date: 31 Mar 91 05:52:41 GMT
References: <2845@shodha.enet.dec.com> <1998@kuling.UUCP> <2832@shodha.enet.dec.com> <1991Mar28.152952.18380@rice.edu>
Organization: Eric's Amiga 2000 @ Home
Lines: 78

From article <2845@shodha.enet.dec.com>, by devine@shodha.enet.dec.com (Bob Devine):
> However, the point I would like to make is that the processors are
> beating the rest of the system for performance.  Many problems
> that were cpu-bound are now I/O bound or have bottlenecks that moved.

Looking at the LFS paper, with enough memory, disk caching can keep up to
90% of the disk working-set in RAM for "typical" users.

This, however, ignores two particular application sticky points: random
access of large databases, and streamed access of large data sets. Often
large databases in the commercial world take up entire disk ranches, with
minimal predictability regardless of any cache size you can think of. The
possibility of a disk heirarchy (similar to the early days) of large slow
disk and smaller faster disk isn't really valid, because you simply can't
predict where you're getting data next (except perhaps for often-accessed
index files and such, but RAM cache can often handle that). The only real
answer there is what the mainframe folks do -- a bunch of controllers and
disks, and do things in parallel (disk access wise) as much as possible.

Sequential access... operating systems are the basic foe here. Many
operating systems do not contain provisions for easily streaming files into
a user's dataspace. To some extent virtual memory is an enemy here... what
is, on a non-VM machine, a simple operation (simply hand off the address of
the user's data space to the DMA disk controller, and go do something else
while it streams the entire file into memory) becomes fraught with
complexity when dealing with a MMU. If I recall right, the vast majority of
Unix kernals basically do I/O a block at a time into cache RAM, then copy
it by hand into the user's data buffers. Some do pre-reading, which
speeds sequential access, but puts random access into the doghouse
(because everytime the user asks for a random block, the disk system
transfers twice as much data as what the user really wants). The caching is
nice when dealing with compilers and text editors and such, which will be
swiftly re-used. But when you're bringing in a huge array to feed to the
array processor, you're most likely not going to bring that array back into
memory anytime soon. Blowing the cache out of the water and then doing a
memory-to-memory copy of a huge amount of data doesn't strike me as too
attractive of a thing to do.

Which brings us back to the question of storage heirarchies. As established
elsewhere, for "normal" usage the memory cache is quite adequate for
maintaining a "working set" of the disk drive. For random access no cache
really works too well (except perhaps for index files), and about the only
sort of "disk" that would be suitable for an intermediate position would be
a "ram disk". Which is possible, and I do seem to recall that some folks
have put something of the sort out on the market. Someone else will have to
supply details on that. But no miracles here.

And finally, for sequential access, when you're continually streaming
multi-megabyte files into memory one after the other, forget about
caching... all you can do there is concentrate on things like, e.g., data
striping, getting multiple i/o channels pouring their data into memory as
fast as the memory system will handle. And with things such as, e.g., wide
memory busses, you can design memory systems that'll handle sequential
accesses basically as fast as you have money for.

In other words, in the cpu/memory/disk heirarchy, a) there isn't any need
for an additional level in the general case (90% cached in memory, when
enough memory), b) an additional RAM-disk might be suitable to put between
memory and disk for random access, if it's not cheaper to just add memory
to the main CPU to begin with, c) any heirarchy you can think of won't help
sequential access, all that'll help there is simply improving bandwidth.

> The basic cpu/memory/disk hierarchy has been expanding so that at
> each of the interfaces more levels will be used.  There are a few
> companies that are looking at the storage issues but no revolutionary
> proposal has emerged -- news on that was what I was fishing for...

Revolutions, alas, happen only once every 200 years or so. The last major
revision was when the disk heirarchy contracted from disk/drum to just
plain disk. Unless research says that for large databases a large cheap
RAM cache between disk and CPU is viable, things are likely to stay as they
are heirarchy-wise. The factor implicit in two-level CPU caches (lack of
space for large on-chip caches) doesn't hold when we're talking disk.

--
Eric Lee Green   (318) 984-1820  P.O. Box 92191  Lafayette, LA 70509
elg@elgamy.RAIDERNET.COM               uunet!mjbtn!raider!elgamy!elg
 Looking for a job... tips, leads appreciated... inquire within...