This may seem a little bizarre, and I haven't fully fleshed out the idea yet (Just hit me reading the board), but I wanted to get a few opinions on whether it's worth pursuing.
Traditionally every process has it's own page directory complete with page tables and PTE's.
What I'm proposing is that instead of this each process only has a page table (Or multiple page tables if the process is sufficiently large).
This is how it would work:
Initially all page tables aside from the kernel's are marked not present (Kernel page table is present in every process). When a process is switched in its page tables are marked present and the process restarted.
Any attempt to access areas outside its own page tables would result in a page fault. The faulting address can be checked against a list of per-process allowed entry points to make for easy libraries/IPC, and result in a terminal error if not allowed.
When switched out the scheduler marks the page tables as not present, and the sequence begins again.
***
Upsides:
There is no need to load CR3 or fully flush the TLBs on every context switch.
4k is released for every process thanks to not needing a page directory.
Downsides:
Each page table is only 4Mb of address space, so a large process will need more management.
There would still need to be mechanism to add another page directory if a large number of processes are being run.
Application code would ALL have to be position independent (With the attendant loss of a register, or loader linking overhead)[sup]1[/sup].
***
[sup]1[/sup] If a GDT entry pair was produced per process then this problem would be solved. Such a scheme would also remove the need to mark page tables not present, since going outside the selector limit would produce a fault. Process page tables would have to be contiguous though, and the IPC advantage might be lost. Plus it's not very portable to newer architectures.
***
As I said it's a strange little scheme. Comments (Even "You're mad!"), suggestions and discussion welcome.
Paging idea...
Re:Paging idea...
What you have invented (more or less) is the concept of small adress spaces. This is not so crazy, and it's been used especially for drivers in microkernels.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Paging idea...
yup, there are even microsoft researchers looking at this directions (and implementing things like "thread tunnelling" over it).
The main problem i see about it (tell me if i'm wrong) is that at the time of a switch, you manually have to discard all of the process's pages before you reload page tables with the new process ... otherwise the new process could accidently access the old process pages because they're still mapped by the TLB.
I'm also very unsure of what it'll give on multi-processor systems ...
The main problem i see about it (tell me if i'm wrong) is that at the time of a switch, you manually have to discard all of the process's pages before you reload page tables with the new process ... otherwise the new process could accidently access the old process pages because they're still mapped by the TLB.
I'm also very unsure of what it'll give on multi-processor systems ...
Re:Paging idea...
You can avoid TLB flushes by using segments to rebase (and limit) the address space instead. So in a sense, all the processes sharing the page directory COULD see each other's data, IF they could get their hands to a regular 4GB code/data segments descriptors.