I wondered about this once, and was, ahhh, "discouraged" from this line of
thinking, but perhaps you want to write some code.

On the 486 (and I assume Pentii) each task on the 486 has a maximum of
2^14-1 (16K) selectors, and offsets can be 2^32 bytes, giving a total of
2^46 bytes (or 64 terabytes) of logical address space per task.  (A selector
is the contents of a segment register).  That's 70,364,449,210,368 bytes
per task.

Presumably it's just a few quick hacks to throw this into the kernel...
(People, I'm -joking- !;)

-Mike


On Mon, 16 Oct 2000, Alicia da Conceicao wrote:

> Memory maps provide the most efficent means of randomly accessing data
> within a file.  However they cannot be used for a file that exceed the
> available address space for a process (2 GB - 1B), used by signed 32 bit
> pointers.  In fact the available address space has to be shared by all
> memory mapped files loaded by the process.
> 
> Is there an efficent alternative to memory maps for huge (> 10 GB) files
> on NetBSD ix86, that can be used for many random database accesses.  I am
> hoping for a solution which doesn't involve many, many seeks & reads, or
> constant loading & unloading of memory maps containing small sections of
> each file?
> 
> Yes I know that 64 bit hardware like Sparc64, Alpha, & Mac can memory map
> huge files, but I need a solution for 32 bit ix86 hardware, since these
> are to be deployed on the client side with cheap, existing PC computers.
> 
> Writing alternatives to tail & more/less that work using seek & read
> instead of memory maps would be quite easy to do.  But for applications
> that needs to read large amounts of data in random order from multiple 
> huge (> 10 GB) files, using many, many seeks & reads would be too
> inefficent.
>  
> Any advice on an efficent NetBSD ix86 memory map alternative for huge
> files would be appreciated.  Maybe combining some type of elaborate
> caching with seek & reads, like that which is done at the kernel level 
> with mmap's "SYS_mmap" system call?
>  
> Thanks in advance. 
> Alicia.
>  
>