lkml.org 
[lkml]   [2002]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: i686 SMP systems with more then 12 GB ram with 2.4.x kernel ?
Date

In message <E16LTvs-00016I-00@the-village.bc.nu>, > : Alan Cox writes:

> > 2. Isn't the boundary at 2^30 really irrelevant and the three "correct"
> > zones are (0 - 2^24-1), (2^24 - 2^32-1) and (2^32 - 2^36-1)?
>
> Nope. The limit for directly mapped memory is 2^30.

The limit *per L1 Page Table Base Pointer*, that is. You could
in theory have a different L1 Page Table base pointer for each
task (including each proc 0 in linux). You can also pull a few
tricks such as instantiating a 4 GB kernel virtual address space
while in kernel mode (using a virtual windowing mechanism as is used
for high mem today to map in user space for copying in data from
user space if/when needed). The latter takes some tricky code to
get mapping correct but it wasn't a lot of code in PTX. Just needed
a lot of careful thought, review, testing, etc.

I don't know if there are real examples of large memory systems
exhausting the ~1 GB of kernel virtual address space on machines
with > 12-32 GB of physical memory (we had this problem in PTX which
created the need for a larger kernel virtual address space in some
contexts).

> > 3. On a system without ISA DMA devices, can DMA and low be merged into a
> > single zone?
>
> Rarely. PCI vendors are not exactly angels when it comes to implementing
> all 32bits of a DMA transfer

Would be nice to have a config option like "CONFIG_PCI_36" to imply
that all devices on a PAE system were able to access all of memory,
globally removing the need for bounce buffering and allowing a native
PCI setup for mapping memory addresses...

gerrit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.070 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site