On 8/17/05, Oliver Korpilla <Oliver.Korpilla@xxxxxx> wrote: > Am Mittwoch, den 17.08.2005, 11:52 +0530 schrieb Aditya Godbole: > > Hi, > > > > I have an elementary question. Is the page table mapping for himem memory > > areas a global mapping or is it different for every process address space? > > > > If all processes share the same himem memory mapping, why is it so? Wouldn't > > it give more flexibility if the himem mapping is different for different > > processes, just like regular memory? (Though I can think of drivers for himem > > mapped devices that can benefit from this scheme). > > > > If the memory mapping is different for every process, why do we need a > > waitqueue for the 128MB that maps the himem? > > It is the same for all processes combined. The kernel maps in the high > memory pages in its top 128 MB (speaking of 32 bit now) of its GB of the > address space. > > This is because the kernel might want to access process memory, or needs > to handle a fully 32 bit capable DMA device (which can see a full 4 GB > physical address space). > > All processes share the kernel in its last GB of the mapping, so we > don't need to throw away all address translations (virtual <-> physical) > on context switch to and from supervisor mode. The kernel wants, e.g. > for the reasons above, access to the memory of all processes to do its > job. So the kernel needs to map in certain parts for some operations > into its address space as high memory. This has to happen within the > kernel part of the address space for 3 reasons: > * Protection from unauthorized user access. > * Kernel addresses are not allowed to page fault, unlike user space > addresses. This is why we have macros like copy_from_user(), to avoid > that a paged-out page makes the kernel have a page fault. > * Therefore the kernel references in its address space real physical RAM > instead of process page tables, because the first represents pages > present in the RAM, while the second represents the status of the pages > of an address space (and therefore page faults are possible for > paged-out pages). The kernel mapping of RAM can not fault because it is > always backed by real memory. > > So you need the window to map in real memory into the kernel address > space, and its size is limited. > I want to add some thing to Oliver's Answer !!!!! AFAIK processor deals with pages tables and virtual addresses for accessing physical memory, and the page table (PGD) base entry was loaded in CR3 register and with PAE enabled (Processor able to access upto 64GB) all page table entries become 64bit wide, but the CR3 register remains 32bit in width, So the page table entries (PGD, PMD, PTE) must lie in the 32bit virtual address limitation (0 to 4GB) and in kernel it lie in 3GB to 4GB of virtual address range. So the page tables were built in kernel virtual address space, and for accessing Highmemory (from 1 GB upto 64GB) it have to create a mapping in page table for the physical address to access and these table entries for mapping highmemory are limitted in number ..... see kmap or kmap_atomic !!!!! -- Fawad Lateef -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
