[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: PGD Modification
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/