Re: [RFC] VM: I have a dream...

[Bryan Henderson <hbryan@us.ibm.com>]

>1) IF the ONLY reason this was not done before is that 64-bit archs 
>were hard to get, then you are right.
>
>2) IF there were OTHER reasons, then you are not correct.
>
>This is the argument.  You keep discussing how 64-bit archs were not 
>easily available before and are now, and I AGREE, but that is NOT 
>RELEVANT to the point he made. 

As I remember it, my argument was that single level storage was known and 
practical for 25 years and people did not flock to it, therefore they must 
not see it as useful.  So if 64 bit processors were not available enough 
during that time, that blows away my argument, because people might have 
liked the idea but just couldn't afford the necessary address width.  It 
doesn't matter if there were other reasons to shun the technology; all it 
takes is one.  And if 64 bit processors are more available today, that 
might tip the balance in favor of making the change away from multilevel 
storage.

But I don't really buy that 64 bit processors weren't available until 
recently.  I think they weren't produced in commodity fashion because 
people didn't have a need for them.  They saw what you can do with 128 bit 
addresses (i.e. single level storage) in the IBM I Series line, but 
weren't impressed.  People added lots of other new technology to the 
mainstream CPU lines, but not additional address bits.  Not until they 
wanted to address more than 4G of main memory at a time did they see any 
reason to make 64 bit processors in volume.

Ergo, I do think it was something bigger that made the industry stick with 
traditional multilevel storage all these years.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/