lkml.org 
[lkml]   [2006]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] VM: I have a dream...
From
Date
>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/

\
 
 \ /
  Last update: 2006-02-01 00:16    [W:0.140 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site