re: CVS commit: src/sys/uvm

[matthew green <mrg%eterna.com.au@localhost>]

> > So I guess we won't be switching pg->phys_addr from paddr to pfn?
> > Speaking of which, any plans for expanding to >32-bit (or >31-bit, if
> > signed) pfns in the rest of uvm?
> 
> That's not part of my current plans for UVM, which right now extend only as
> far as breaking the back of the performance problems with builds.  31 bit
> pfns get us into the terabyte range I think.  I have a couple of thoughts
> here, firstly SVR4 or Solaris has a pfn_t and pgcnt_t or something like that
> and it would would be nice to have an analogue.  Kind of surprised we didn't
> inherit something like that from Mach.

FWIW, the numbers are: we break at 8TiB ram, that's where
the 32 bit signed overflow happens.

the other number of note: HP sell a machine with 48TiB of
ram already, since most of last year if not more.

another method would be to lie to UVM and provide it with
>4KiB pages to manage, like VAX already does.


.mrg.