lkml.org 
[lkml]   [2000]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: large memory support for x86
Timur Tabi writes:
> ** Reply to message from Jeff Epler <jepler@inetnebr.com> on Thu, 12 Oct 2000
> 13:08:19 -0500
> > What the support for >4G of memory on x86 is about, is the "PAE", Page Address
> > Extension, supported on P6 generation of machines, as well as on Athlons
> > (I think). With these, the kernel can use >4G of memory, but it still can't
> > present a >32bit address space to user processes. But you could have 8G
> > physical RAM and run 4 ~2G or 2 ~4G processes simultaneously in core.
>
> How about the kernel itself? How do I access the memory above 4GB inside a
> device driver?

It depends on what you have already. If you're given a (kernel)
virtual address, just dereference it. The unit of currency for
physical pages is the "struct page". If you want to allocate a
physical page for your own use (from anywhere in physical memory)
them you do

struct page *page = alloc_page(GFP_FOO);

If you want to read/write to that page directly from kernel space
then you need to map it into kernel space:

char *va = kmap(page);
/* read/write from the page starting at virtual address va */
kunmap(va);

The implementations of kmap and kunmap are such that mappings are
cached (within reason) so it's "reasonable" fast doing kmap/kunmap.
If you want to do something else with the page (like get some I/O
done to/from it) then the new (and forthcoming) kiobuf functions
take struct page units and handle all the internal mapping gubbins
without you having to worry about it.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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