OSDev.org

My OS doesn't have yet any disk controller, but already has a memory manager. What can I do except panicking when a page fault occurs?

If a page fault occurs is very likely that a big problem has occurred that should be fixed. Until you actually swap out pages, the page fault handler should inform you of a problem, because it should be fixed.

That said, it could kill the task that caused the page fault, or something like that.

-JL

the page fault handler should inform you of a problem, because it should be fixed.

And how can I recover from it? I don't know what to fix if that happens, and when I didn't halt, after the interrupt it will continue running but then a double fault will occur followed by a triple fault.

Kill the task that caused the page fault, if it's in usermode. If a kernel-based thread caused the fault, panic or something. Not every page fault means instant death for the OS

leledumbo wrote:

the page fault handler should inform you of a problem, because it should be fixed.

And how can I recover from it? I don't know what to fix if that happens, and when I didn't halt, after the interrupt it will continue running but then a double fault will occur followed by a triple fault.

He meant that you should fix your code. A pagefault implies a bug, unless your OS has progressed to advanced levels (and by then you'll know which pagefaults aren't bugs).

Hi, in my OS, before i implemented swapping, i implemented lazy memory allocation using the page fault mechanism. In this system when an ap(or even the OS) requests memory through mmap(or similar) you keep a record of it but dont actually assign any physical memory yet. When you get a page fault you can then check your records for the app and if memory was supposed to be allocated at that point map in a physical page. This is approach is more memory efficient because it only assigns physical memory when needed but it does have performance costs due to extra pagefaults so its not best in every situation.

Just a quick idea of how you can use pagefaults before you get swap implemented.

Thanks, PinkyNoBrain. I think I can use that solution until I have a disk controller.

@ PinkyNoBrain, leledumbo:

That approach actually brings about a serious problem (which, AFAIK, all Unixes suffer from): The allocation might succeed, but when the page fault is triggered, you might be out of memory and cannot serve the page fault handler.

From the user space perspective, your malloc() succeeded (returned a non-NULL address), but you still get an error when trying to access the memory.

That one's a b*tch to debug if you don't know what's going on...

Linux features the OOM Killer for this reason: It herustically evaluates which process is the memory hog (And gets it right most of the time, unless, it seems, you're running a DB server. Particularly Postgres), which is arguably a better solution than a random process SIGSEGVing because it just grew its stack, or a different process SIGABRTing because new just threw (Or a sloppy process dying because it used a malloc-returned NULL).

(EDIT: And note the OOM killer is not designed to protect against malicious processes: rlimits are for that. A process can legally make itself not be invulnerable to the killer, in which case it will only be killed if the alternative was to panic)

Well, one could keep track of the number of pages that have been committed, and refuse to commit more pages if the total number of pages exceed available memory. This way, you can map pages dynamically while still knowing if an allocation is successful at the time the allocation is made. This is most useful when swapping is also implemented, but can also be useful if it's not (since pages don't have to be zeroed immediately, if they are to be zeroed).

You'd have to be careful for when your use counter matches the available memory, and somewhere you find yourself in need of a new pagetable to actually give out that memory...

Owen wrote:Linux features the OOM Killer...

Linux breaks the contract of malloc() and new().

Solar wrote:

Owen wrote:Linux features the OOM Killer...

Linux breaks the contract of malloc() and new().

As does FreeBSD. As does OpenBSD. As does NetBSD. As does Solaris. As does Mac OS X. As does Windows.

I think by now the contract is so well and truely broken that it can be considered void. Certainly, breaking the contract has brought with it performance improvements.

Owen wrote:As does FreeBSD. As does OpenBSD. As does NetBSD. As does Solaris. As does Mac OS X. As does Windows.

Windows doesn't break the contract of malloc and new, at least not in the way that's being discussed in this thread. The kernel only allows a virtual memory allocation if it doesn't exhaust the machine's overall commit limit, which is the amount of pageable physical RAM plus the size of the page file.