OSDev.org

Ok, so I did a basic virtual memory manager design, which quite easily handles your basic things including demand-loading, shared-memory and copy-on-write and any sane combination of the above (say, demand-loaded region, private copy-on-write copy of that shared by a few processes and another copy-on-write logical copy of the shared region).

So in short, it's the basic thing you'd expect. It's definitely not the most efficient possible design, and (unfortunately) I don't have a working proof-of-concept yet (I'm going to write one in the future, improving the design as I progress). In any case, I wrote the design in the form of a tutorial, and it's available for you to read and comment (and possibly even learn).

It's quite high-level stuff, and even the code that it contains is really not intended for computers but only humans. But since most virtual memory tutorials seem to concentrate on hardware mechanisms, I though I'd write about the stuff above hardware. So no page-directory management here.

The text is a mess for now, so if somebody wants to mirror a copy, please tell me so I can notify you of updates. Also, I think I'll add some figure later so things are easier to understand.

Suggestion are welcome, questions are encouraged, and all the usual stuff. Address is:
http://www.cs.hut.fi/~tvoipio/memtutor.html

Good text.

One question which troubles me all the while, so I think, here is the appropriate location to place it:

you say, the swapper checks whether a region/page is dirty or not - so to say it's been accessed.

How does the OS recognize that a page 's been accessed or even better - written to? I know, the processor sets some bit in the page table entry, but how does the operating system gets intelligence of this?

I s'pose, that we set the pages read only. Upon writing attempt, the process first traps into the page handler, which checks:

1. page present.
2. page belongs to this process.
3. page is usually read/write. -> change readonly to write and set the dirty flag.
4. restart the process.
5. upon next run of the swapper: check the page flags, and if it is dirty and read/write - clear dirty flag and set to read only again.

I reckon having the page handler do the dirty work is the central clue to this.

Aside from this: My regions are called page arrays. they can be shared by multiple processes. But I have not yet had the idea to link "vmm per process book keeping info" also in a double linked list. excellent input.

I think I might actually want to check existing literature for what's the common terms for what I call regions and mappings, just to avoid causing unnecessary confusion when people read several tutorials.

Thanks for the input though. The collection of dirty (and used) bits certainly needs some clarification. Here's a short version: you don't mark stuff read-only just to see if somethings written to. If you did, you'd take unnecessary page-faults, and that'd be slow. Yeah, it's easy to do and works, but it's unefficient.

I'm relying on the assumption that the swapper isn't time-critical task in the sense that most kernel tasks are. So the idea is to see if a process has been run. If it hasn't, there's nothing new dirty. If it has run, then checking the page-tables tells what pages are dirty. Just map them temporarily somewhere. So what my swapper-design does go find all the dirty bits from those processes which have been running since the last check, and if any of them has a dirty bit set, then the page in question is dirty.

Besides, you probably want to collect the "used"-bits as well (to avoid trashing) so you have to visit the page tables anyway, unless you want to serve page-faults all the time. IMHO it is better to slow down the swapper than add more overhead to normal processing.

I think I'll reconsider both the swapper design and the text about it, and try to clarify them. Good that you brought the issue up...

mystran wrote: I think I might actually want to check existing literature for what's the common terms for what I call regions and mappings, just to avoid causing unnecessary confusion when people read several tutorials.

You may want to keep in mind the conceptual idea of the terminology you are using, rather than the specific names. You have a name for them, and it is very good that you define what those things mean to you. beyond infinity has a name for those things, my kernel has a different name, all other kernels have different names for it, etc.

I was going to mention that it is always a good idea to provide external references (whther they be books or online resources) for stuff like this. Your tutorial is quite good, but further reading is always beneficial, and only aids in the overall credibility of the work. It seems you had this in mind already anyway.

While reading your tutorial I was pretty excited to see similarity between the API you are providing and the API that exists in the small VMM that I've began implementing. I quicly realized that your structures are indeed different names, but conceptually they had nearly identical usage. I guess this isn't too surprising if you consider the purpose of a VMM and the process that so many of us go through to get more advanced functionality (also considering the resources on these subjects).