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'm a bit out of the details, I admit. ;)))) Maybe you get a copy of "Understanding the Linux Virtual Memory Manager" from Prentice Hall, it explains this best. The ways around this are: * Patching your kernel to 2GB or 4x4 or something like that. * Getting a 64 bit processor (e.g. a x86_64 in long mode). With kind regards, Oliver Korpilla -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
