> I've been lurking on this list for some time.
> I recently read that the Pentium II - XEON
> chip supposedly has capability to use a 36 bit
> address space, with up to a 2 MB page size.
sort of. x86 has a 32b flat address space. period.
the 36b extensions require the use of segmentation, and therefore,
in the inherently flat traditional Unix programming model, need some
form of OS-assisted bank switching. when this was last discussed
on linux-kernel, the tone from kernel gods was rather dubious...
> Rather than post to Linux-kernel, I ask here...
> What sort of work would be needed to adapt the
> Linux 2.2.xx kernel for a quad Xeon, and an
> 8 GB core space (i.e. 8GB physical RAM)?
pretty icky stuff. first, a Linux process on x86 will almost certainly
never address >4G (that is, use segmentation.) the main question is
whether it's worthwhile to add 36b kruft at all: I think the first
requirement would probably be that 32b must not become at all slower.
> accomodate up to 8 GB of RAM, yet there seems
> to be a physical RAM limit of about 1 GB with
> the 32 bit P-II's. (I saw a previous posting
first, Xeons are not in any way special: they're just Celerons with
bigger caches (or, alternatively, PII/PIII's with big, full-speed caches).
1/3 or 2/2 are achievable (physical/virtual). it's conceivable
that Linus and the others will work around the p+v<=4 issue, perhaps
even on the way to supporting 36b. during the last linux-kernel
discusson on this, there was some sentiment expressed along the lines of
"if you want to spend that kind of money, do it on a sane ISA like
Sparc, Alpha, MIPS, etc". this seems quite sensible to me,
since big x86 ram does _not_ come cheap: boxes of that category are
in the same price range as, say a DS20 Alpha from DEC/Compaq.
> GB of core (RAM) is addressable. I think this
> is a limitation of the 32 bit Intel memory model.
x86 programs are indeed limited to <=4G flat address space,
but the current kernel policy of p+v<=4 could be changed. the issue
has mainly to do with things like arranging device access (32b)
to memory in 36b. on linux-kernel, there was some discussion of
how this might not be a major performance problem, since big-memory
programs might not do much IO, and almost certainly don't want to swap...
regards, mark hahn.
--
operator may differ from spokesperson. [EMAIL PROTECTED]
http://java.mcmaster.ca/~hahn
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
