Hello..
Note those pages now could have two mapping (if they lies inside normal
and DMA zone), one is via identity mapping, one is that process's own
mapping
Does that mean that kernel memory is swappable/context switched. I.e. when the
process is "current", he can address the same physical address the kernel
will when the process is still in the run queue but not "current".
Sorry, I don't understand what you're saying here. Could you elaborate?
If the kernel wants more, it can do so via temporary mapping (kmap()).
By doing it, the highmem pages will be temporarily mapped in the area
slightly beyond the end of kernel identity mapping (AFAIK, this is the
one we know as the upper 128 MB area, use for vmalloc, fixed linear
I think vmalloc also takes first from the normal zone (since it actually uses
kmalloc IIRC).
No, you misunderstood me. I was talking about the "mapping" window, a
place where pages are mapped before they can be accessed. Of course
vmalloc() itself can get free pages from any zone including normal zone.
Also, i am trying to understand this identity mapping. I understand it's
simplicity, but how the MMU uses this fact? is it still uses page tables for
this? since this would be very wasteful.
Yes, it is done by setting up page tables. This is the only way AFAIK,
since we are dealing with x86 protected mode. In other architectures, it
might be done diferrently but I don't know how they do it.
In addition, i understand that in (no pae) x86 32bit you have 1MB of 4 bytes
entries that can be referenced by the MMU (which, i think, can only address
1gb of ram pages).
Not sure if I get this part.... are you referencing about the overall
size of page table entries (PTE)?
Does this mean that the kernel has to change the page
tables as necessary, i.e. when a process does context switch and needs the
same virtual page address used by a different process. Does the kernel leaves
there (in the MMU current page tables) some entries of its own constantly?
Ok, although honestly I didn't fully understand your Q above, I think I
got the essence. OK, back to the fact that (let's say 3:1 VM split)
kernel space is mapped in the upper 1GB space. When the current running
process is changing (via process switch), the active PGD (page global
directory) (thus also the active PTEs) is also changing. Since in each
task_struct, there is a pointer keeping the pointer to the process's
PGD, the kernel simply fill the cr3 register with this address and the
MMU will recognize the whole new address space set.
What about the kernel space? Is it changing when process is switching?
No, it stays there because every processes are practically use the same
kernel mapping for the upper 1GB space. I forgot the details nor which
part of kernel codes that doing this, so that's the best I can descibe
right now. However, a different situation happens in unique VM split
such as 4:4 ... there kernel mapping is not directly mapped to every
processes, so the context/process switch is more costly compared to
3:1/2:2/1:3 VM split.... but in the other hand you have the whole
address space either in user space or kernel space. A tiny space is
reserved, however, for so called "trampoline" codes. This "trampoline"
acts as a bridge that allow to jump from user space to kernel space or
vice versa.
Anybody can jump in to CMIIW.
regards,
Mulyadi.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
