Hi Bahadir ... At this point, I am just giving my personal thoughts... so don't take it too seriously :) > Yes I mean't the kernel mappings. This is probably quite > arch-specific, but AFAIK a PGD is maintained for each process, and > since the kernel area is fixed, (assuming 1G/3G mapping) it only > requires changing the (cr0 on x86?) pgd pointer register and a > tlb/cache flush upon a context switch. PS: don't forget, not every process owned a unique PGD...just think about cloned process (with CLONE_VM flag set, for example). And yes, you just need to update cr3..and voila TLB will be flushed (not sure whether it is a full flush or partial). In 4/4 vm split, things are a bit different anyway....mapping are changing when you enter/exit kernel/user mode IIRC. > I was expecting that the kernel memory allocators, (buddy/slab and > anything else allocation related) would change the kernel mappings > frequently if not always, when some memory is allocated to user or > kernel space. The question is, is it really frequent, if at all? IMHO, if a page is already handed to user space, means user space will have its own page table entry that will translate the virtual address to this physical page. So, unless there is a fault somewhere in kernel memory allocator (or glibc allocator itself), kernel will know that the related page is still used and won't be deleted. Whether the kernel maps this page into another virtual address, IMHO again, it's not a problem... > If the whole of physical memory (up to 4GB in a 32-bit system) is Don't forget, not all those 4 Gig are mapped by kernel. At most, only 896 MB are mapped in 3/1 VM split.... > virtually mapped to the kernel at initialisation, then any time > userland wants memory, tables need modification. Yes, kernel allocates the page, mark it as used and "handed it down" to user space. By handed down, I mean updating that process page tables entry... kernel space itself can still access these pages via identical mapping ( for pages under 896 MB limit) or kmap ( > 896 MB) >Else if it is > partially mapped, as kernel runs out of mapped memory, tables (most > possibly pgds, since they map for bigger chunks) would need > modification. Does anyone know how this is done precisely, say, on > x86? I am sorry, I didn't get on what you mean by "partially mapped", could you elaborate it? > Back to your comment, lazy modification makes sense, since pgds won't > need updating unless the process it belongs to is scheduled to run. yes, imagine 10000 processes, a single kernel space PGD entry modification and all those 10000 processes are updated at once? Oh my.... :) regards, Mulyadi. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
