[...]
> There are many complexities with very large files, e.g. >>2gb,
> especially when you consider mmap, etc.
>
> But, it seems there might be a simpler `half-way' case which won't
> require lots of vm reworking, for files between 2gb and the maximum
> size of userland, normally 3GB.
>
> Even when/if we do support obscenely large files (e.g. 10GB) for
> Intel, we still will only ever be able to mmap a small part of them.
Well, not totally. There is the posiblity that the Intel engineers
offered us for addressing more than one single 32 bit space:
segmentation.
Screams and flashbacks to working under DOS and Win31 aside, using the
segment support with the Inter CPU line it should be possible to address
a large number of 4GB memory spaces using a segment register loaded with
an alternate segment descriptor.
Having actually played with a little OS development using 32bit code
with a non-flat memory model, this has a few advantages; I was able to
provide support for executables with 4GB code, 4GB data, 4GB stack, all
completely seperate. Of course the physical memory wasn't there; it was
mostly just a project to determine if this could be done.
This might be the model for providing a 64 bit (or greater) size mmap
function; return a bunch of 4GB segments that each contain an apropriate
part of the file. A compiler that deals with segment:offset pointers
politely would then present this as one single, contiguous address space
larger than the individual address limits.
Disclamer: I know zero (0) about the Linux MM layer; this is just noting
that the hardware could support the mmap on IA-32...
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html