OSDev.org

Hey I have a couple of questions regarding the implementation of paging into my OS. I'm pretty sure everything except this is clear in my mind. Perhaps I'm looking at this all wrong but here it is:

When you do a task switch assuming you switch PageDir which interm switches Page Tables and Pages how does the memory currently stored in there get preserved for when the task is rescheduled? Is this something to do with the actual task state saving itself or is it something to do with the paging aspect?

Thanks.

all your virtual addresses setup is defined by the content of pg dir and pg tables, so as soon as you reload CR3 with the address of the now-re-scheduled-task, any memory reference will be resolved using the reloaded page directory.

In other words, all you have to do to "preserve" a sleeping task's address space is to ensure that it has its own page directory and that noone is messing up with its page tables.

this is not as complicated as you think:

Brendan has provided a nice means to illustrate how pagedirs might look like:

say u = user process, k = kernel,x = naught (I simplyfy to ease understanding)

now we can establish a simplyfied table of page directories as follows:
[edit]
@pype: better that way?


where 1,2,3,4 stands for the according processes (address spaces)

Kernel k is, as you can see, mapped into each process.

So, assuming that there won't be any page table updates pending for kernel land, you'll have the same kernel memory area mapped into each process (unlike the memory entities mapped into the processes, which are completely unrelated to each other). This is good: In kernel land reside the TCB's (task control blocks) in which you store scheduling data, context data AND address space stuff (cr3, vmm allocation tree etc).

So, upon task switch, you take a tcb, check if you need to switch address space and then return to the task referred to by the current tcb (by restoring register content)

The memory entities remain. What has been written into the memory of the previous task will be invisible to the new task in case we are switching address spaces (reloading cr3) unless it resides in a memory area shared between the two of them.

register contents reside with the tcb in kernel land, so no worry about them. they remain where they are.

Hope this helps.

just in case ... i know i would have found the above more illustrative ...

Thanks guys that really cleared it up.