Handling changing need for pagetables?

[Freanan]

At compile time noone exactly knows how much of the 1024
possible page tables will be needed at runtime.
Do you just set up page tables for all 4gb of
the kernel's or a user process's adress space initially
so that you do not have to take care of them
or do you dynamically allocate new pages to put pagetables in
them whenever new ones are needed?
The first approach is probably faster, but less memory efficient.
Are there more points speaking for approach 1 or approach 2,
rendering one of them not feasible? Or is it just a matter of "taste"/design?

[AR]

Preallocating is entirely possible but it is quite wasteful, especially since not all of the program will be in memory at the same time anyway (page swapping). If you want to then you can, but the logic for creating the page table when there isn't one is not very complex (although it does put you at risk of allocating the page then realising you need a page table but there isn't any pages left in which case you would just trigger the swapping code anyway).

Using preallocation may be useful in helping you to get your process management and scheduler working then you can "fix" it later.

[Ushma]

A similar question: http://www.mega-tokyo.com/forum/index.p ... eadid=7403

[Freanan]

Thanks, i think i will refrain from preallocating and create new pagetables on demand instead.

[Crazed123]

Yep. A process's initial working set of pages (basically, its initial code and data sections) should be preallocated. Page tables shouldn't.

[Ushma]

That's debatable. The working set could really start with 0 pages, and upon first entry, there's a page fault to get the first code page. Demand-page the whole image. You could avoid loading parts the program is only going to need much later, or may never need. No reason to load the whole thing and allocate the whole thing.

[AR]

I would think loading at least the page containing the entrypoint would be a better idea because you can guarantee that at least it will be used and it would be inefficient to demand page it.

[Colonel Kernel]

I would think loading at least the page containing the entrypoint would be a better idea because you can guarantee that at least it will be used and it would be inefficient to demand page it.

What's the difference in performance between demand-paging in the first page, and "pre-paging" it?

One of Windows' niftier tricks (not sure how well it works, but it sounds neat) is to measure the order in which each app faults in its executable code, and then re-order the disk blocks of those executables to minimize disk head seek-time on the in-page I/O.

[AR]

Simple, start task > switch > page fault > switch back to kernel and load page > switch back to task and resume execution. versus start task > load page > switch and run.

It's suprising with all these optimizations that it is still slow, then again they don't actually seem to prioritize virtual memory faults higher then normal disk IO which probably counters that nicely.

[Colonel Kernel]

Simple, start task > switch > page fault > switch back to kernel and load page > switch back to task and resume execution. versus start task > load page > switch and run.

Given the cost of in-paging I/O, I think the extra task switch will hardly make a difference...

It's suprising with all these optimizations that it is still slow, then again they don't actually seem to prioritize virtual memory faults higher then normal disk IO which probably counters that nicely.

Yeah, no kidding. Windows is brain-dead when it comes to prioritizing disk activity. It's one of my least favourite things about it. As long as interactive threads are hung up waiting for disk I/O, the system will never be able to remain responsive under heavy load. This is soooo frustrating to the user (especially the user that runs a few large Virtual PCs and copies of VS.NET 2003 at the same time at work, like me ).