Hi,
On Tue, 08 Dec 1998 08:32:17 PST, Tim Wright <[EMAIL PROTECTED]> said:
> Sequent's DYNIX/ptx does exactly this. With wide (64-bit) ptes, all
> 64GB of physical address space can be addressed. Of course, your
> virtual address space is still limited to 4GB per process, in the case
> of DYNIX/ptx, 3GB for user and 1GB for the kernel.
Linux is the same.
>> Do you know where in the Intel line 36-bit addressing started?
>> I'm curious to know of my PPro can do this.
> Yes it can. AFAIK, all PPROs can do this. Not sure if all PII's can. I seem
> to recall addressing limitations on the "on-chip" L2 cache for the non-server
> type PII chips. Xeon is not so limited.
_Some_ PIIs can, afaik, but not the early models.
> The question here is, how much effort do you want to put into this. We have
> it working because we have to. It is not at all "nice" to implement (the
> combination of a speculating processor, playing games with segments,
> re-writing four L1 ptes instead of one register, and having to handle NMIs
> is an amazingly tricky problem).
We don't have to deal with segments (btw, Linux-2.0 used to play segment
tricks itself to separate user and kernel memory), if we are willing to
restrict kernel memory itself to 1G (we don't have to limit the page
cache, but the buffer cache would have to stay in the first 1G in this
model). The pte problem is not hard in principle: we already have
kernel support for 3-level page tables (the Alpha uses it). What NMI
problems did you have in mind?
> If you want lots of memory, then except in certain specialized cases
> (probably better handled with Beowulf), you probably want lots of
> processors as well. In that case, a great deal more work needs to be
> done on SMP scalability before playing with the VM system to support
> the 32/36bit games on x86.
We already have users running into the memory limits on Linux today.
SMP _is_ improving, fast, and we can't afford to let the VM lag behind.
--Stephen
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
