Bryan Henderson wrote:
> >Perhaps you'd be interested in single-level store architectures, where
> >no distinction is made between memory and storage. IBM uses it in one
> >(or maybe more) of their systems.
>
> It's the IBM Eserver I Series, nee System/38 (A.D. 1980), aka AS/400.
>
> It was expected at one time to be the next generation of computer
> architecture, but it turned out that the computing world had matured to
> the point that it was more important to be backward compatible than to
> push frontiers.
>
> The single 128 bit address space addresses every byte of information in
> the system. The underlying system keeps the majority of it on disk, and
> the logic that loads stuff into electronic memory when it has to be there
> is below the level that any ordinary program would see, much like the
> logic in an IA32 CPU that loads stuff into processor cache. It's worth
> noting that nowhere in an I Series machine is a layer that looks like a
> CPU Linux runs on; it's designed for single level storage from the gates
> on up through the operating system.
>
> I found Al's dream rather vague, which explains why several people
> inferred different ideas from it (and then beat them down). It sort of
> sounds like single level storage, but also like virtual memory and like
> mmap. I assume it's actually supposed to be something different from all
> those.
Not really different, but rather an attempt to use hardware in a
native/direct fashion w/o running circles. But first let's look at the
reasons that led the industry to this mem/disk personality split.
Consider these archs:
bits space
8 256
16 64K
32 4G
64 16GG=16MT
128 256GGGG=256TTT
It follows that with
8 and 16 bits you are forced to split
32 is inbetween
64 is more than enough for most purposes
128 is astronomical for most purposes
:
:
So we have a situation right now that imposes a legacy solution on hardware
that is really screaming (64+) to be taken advantage of. This does not mean
that we have to blow things out of proportion and reinvent the wheel, but
instead revert the workaround that was necessary in the past (-32).
If reverted properly, things should be completely transparent to user-space
and definitely faster, lots faster, especially under load. Think about it.
Thanks!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
