OSDev.org

Does anyone here give every process a seperate Address space and actual create PD's and PT's for every single process as well as a bitmap of which ones are used? When using one address space it worked fine but when i had to create one per process the overhead became huge.. how do you do it?

Tyler wrote:Does anyone here give every process a seperate Address space and actual create PD's and PT's for every single process as well as a bitmap of which ones are used? When using one address space it worked fine but when i had to create one per process the overhead became huge.. how do you do it?

Separate processes - separate address space we call it memory isolation.
To manage virtual address space of process I use algorithm simular to kernel heap malloc/free, they are even derived from same class - FreeMemorySpace

So basically you split the Virtual Address space into isolated address spaces instad of giving every process an entire 4Gb(less the kernel mapping) memory space to work with? I use similar functions but i swap all Page directories and tables to create a new 4Gb address space then map the kernel into the top half of every space. This seems inefficient to me though.

No, every process has its page directory full addres space. Then that address space is splited in smaller blocks (or merged, as needed) when I need to allocate space for thread stack or something like that...

One of the main reasons for entering paging is that we could hand over each process a seperate address space. Though kernel address space should be shared among all process. Basically when creating a new process create a PD and copy all the entries in kernel address space to the new process also.
But how and (when) you are going to update the PD entries of each and every process when allocating memory in kernel space is important.

But wouldnt creating seperate PD's in this way create too much overhead... i tried Using Intels TSS but it simply emant more overhead preparing for it... did anyone have better look with it?

What overhead? 4kb per process? It's not really that big overhead.

kataklinger wrote:What overhead? 4kb per process? It's not really that big overhead.

4K is for the PD... but you still need more pages tables to store all the pages.

No, you map kernel (or shared libraries) PTs to every PD, and that means no overhead at all

kataklinger wrote:No, you map kernel (or shared libraries) PTs to every PD, and that means no overhead at all

ahh.. so your saying dont bother mapping in the tasks code... just other things... genius

Ok let me put this way (if i wasn't clear), you can share kernel PTs between processes (map same PT at same place in PD of all processes). When you create a process you don't need any memory at all except memory of task structure and kernel stack. You can allocate and map it as needed (and that's why it is called virtual memory).

@Kataklinger :
When will you update each process's PD entries. i.e if you are allocating kernel memory will you update the entries for all process (or) if a page fault occurs in kernel space will you check for the PD entries for that process and then update it.

pulsar wrote:@Kataklinger :
When will you update each process's PD entries. i.e if you are allocating kernel memory will you update the entries for all process (or) if a page fault occurs in kernel space will you check for the PD entries for that process and then update it.

I allocate and map all PTs for kernel space at startup (a little waste of memory), when I need to allocte memory for kernel, I just map it to PT and it is mapped in all processes, the I just send an IPI to other processors and wait for them to invalidate TLB.

Hi,

pulsar wrote:@Kataklinger :
When will you update each process's PD entries. i.e if you are allocating kernel memory will you update the entries for all process (or) if a page fault occurs in kernel space will you check for the PD entries for that process and then update it.

For single-CPU systems using "plain 32-bit paging", the kernel's page tables are inserted into all page directories, and the only time you need to be careful is when you change a page directory entry (e.g. allocate or free a page table) in kernel space.

For single-CPU systems using PAE there's a "page directory pointer table" with 4 seperate entries and 4 seperate page directories (one page directory per page directory pointer table entry). Each page directory controls 1 GB of address space. This works out very nicely - the kernel uses one entire page directory (or 2 of them if you want 2 GB of kernel space) and the kernel's page directory (or directories) get put into every page directory pointer table. In this case, the only time you need to be careful is when you change a page directory pointer table entry (e.g. allocate or free a page directoy) in kernel space. In general, this never needs to happen.

For long mode, it's like PAE except there's a table of page directory pointer tables, called the "PLM4" (and each page directory pointer table has 512 entries, instead of 4). There's a few ways to do this, depending on how large your kernel space needs to be. If kernel space can be large, then you could design things such that the only time you need to be careful is when you change a kernel entry in the PLM4 (e.g. allocate or free a page directory pointer table). An easier way is to use a fixed number of "pre-allocated" page directory pointer tables for kernel space so that they never need to be changed (note: a single page directory pointer table controls 512 GB).

This isn't all that hard, once you understand the basics of paging (i.e. from Intel's manuals). The main thing to remember is that (in some of the cases above) you need to be able to access "things" that control parts of the address space for all processes. For example, for "plain 32-bit paging" when you're changing a page directory entry (e.g. allocating or freeing a page table) in kernel space, you need to be able to access all page directories (not just the page directory for the currently running process). I tend to map every page directory into every address space to make this easy...


Cheers,

Brendan