OSDev.org

ok so i'm implementing processes with a pretty good degree of success. So anyway, there is a minor issue with setting up a new process. You need to have access to it's page directory and page tables to set things up.

obviousl for the page directory you HAVE to do temp mapping into the current process to set it up and copy over the kernel page tables, but all other mappings i have 2 solutions and am curious which is better.

#1 quickly switch to the new page dir, map in the new page tables and pages as neccessary, switch to old page dir. all in all less than 10 lines of code..not too bad.

#2 do lots of temporary mappings into the current process and set things up that way. Because i need to ensure that there are page tables in the curernt process to map the pages temporarily and the unmap those when i am done, this code is about 4-5 times longer so about 50-60 lines.

which is more efficient. My gut tells me temp mappings woudl be faster as it doesn't need a context switch.

proxy

Hi,

proxy wrote:which is more efficient. My gut tells me temp mappings woudl be faster as it doesn't need a context switch.

I'd say your gut is right (temp mappings would be faster). It does depend a little on what re-entracy problems this method causes though (what happens if several threads are trying to create several new processes at the same time).

It is possible to avoid the need for any temp mappings, which can work out much better.

I make a permanent mapping of every page directory in kernel space. This allows you to change page directory entries at any time without context switches - for example, if you add a new page table into kernel space you can update all page directories at the same time (regardless of which page directory is currently being used, and without context switches).

After this, you can create a new page directory, map the kernel into it and then start running kernel code in the context of the new process. The kernel's code would set up the remainder of the process, load the executable from disk (or memory map the file, or setup shared pages) and then start running the user level process code.

It's a little faster because you're not creating anything that is only destroyed again later and there can be as little as one context switch between entering the kernel's "create process" code and running as the new process. It's a little simpler because the currently running thread always has the correct page directory and you're not doing any juggling with the paging structures. It can also be much better for re-entrancy lock contention (especially for multi-CPU).


Cheers,

Brendan

Alternatively, you add a "starter" process which on the first switch converts to the thread... (no mucking around with page dirs)

Pete

i'm not sure at what you mean with "all the other mappings". If you want to spawn another process, all you need to map is the process's page directory, no ? All other possible stuff (mapping code, applying COW protection, creating additionnal threads and stuff) can be done when you enter the process for the first time.

okay, there's still one thing you need to map: a kernel stack for the first thread so that you can at least make it start preparing other things, but that's really all i can see ...

well i have not implemented a swap disk/file yet, so that means all pages are mapped in all the time for all processes at the moment. So this means that I need to setup the pages for the code/data/bss sections on process creation.

Eventually i plan to just set it up with the entire program swapped to disk and setup the start/end of each segement of the program. Any access will have the page swapped in.