> > Linus told me the (effective?) limit is actually lower than 1GB for
> > possibly different reasons than the ones you mention (allocation of
> > kernel-space memory vs. user-space memory?), maybe 768 MB.
> >
> > Basically, he said that some settings need to be changed, but it
> > sounded like a minor change.
> >
>
> Well, the problem is basically that all of memory is direct-mapped in
> the kernel address space slot, which is 1 GB in size. This includes
> I/O boards, as well. If you outgrow that slot, then you have to
> change your page tables before you can touch arbitrary memory from
> kernel space, which is a major lose. It can probably be dealt with,
> but it is not a trivial obstacle, unfortunately. One can't even get
> around it by using segment registers, since those still point into the
> 32-bit linear address space.
yes but there should be no problem going as high as 3.9G physical memory
with the current Linux architecture. None of the user-space tools relies
on the size/layout of user-space virtual memory. (up to 2.0G physical
memory is safe when 1 process wants to use up _all_ the memory ... should
be rare)
AFAIR, Sparcs already have a boot-time PAGE_OFFSET variable. For x86 it
shouldnt be much more than to change PAGE_OFFSET, but i havent tried it
yet, there might be some bugs in x86 specific files. [but from the
generic code point of view it's really as simple as to redefine
PAGE_OFFSET and recompile the kernel]
> P6 machines actually have a 36-bit physical address space, but still
> only 32-bit linear...
this is a solution for more than 4G of physical memory, although Linux
will have hard times utilizing it. Question is what will be more common,
4G+ 32 bit boxes, or Klamath boxes ... i'm afraid that it will be the
first one ...
-- mingo