16MB Paging Structure per process?

[KemyLand]

I know this should have an optimal solution, but I can't find it. I've been months ago amazed about the theorical memory requirements of a Paging Structure as per process. Let's analize it deeper:

A Page Directory is made of 1024 Page Directory Entries.
Each Page Directory Entry takes up 4 bytes, and points to a Page Table.
Each Page Table is made of 1024 Page Table Entries.
Each Page Table Entry takes up 4 bytes, and points to a 4KB Physical Address.

So the total size (in bytes) of a full Paging Structure is (1024*4)^2 = 2^24 = 16MB = WTF?

Is there a way to avoid this. I don't want to reserve 16MB of RAM just for paging.

[Nable]

There are such things as large pages and recursive page tables - they are very useful for reducing the size of page tables. Note that you don't have to map the whole 4G space for each process, you can just map those addresses that you will use.
Btw, at least kernel memory is shared between processes. There are other things that can be shared so only unique parts of process's page tables have to be stored separately.

[KemyLand]

There are such things as large pages and recursive page tables - they are very useful for reducing the size of page tables. Btw, you don't have to map the whole 4G space for each process, you can map just those addresses that you will use.

I though of that, but I'm very sure of how to implement it. I though just that (only map what matters). But, how to specify that. If do in userland:

Code: Select all

# Welcome to hackish code!
mov eax, 0xFFFFFFFF

The processor will search for the last page (2^24 - 1), but my page dir is NOT full. Say my kernel's memory map is:

<...> <PageDir for PID 123, 321 pages)> <My little and inocent kernel code > <...>

The processor will probably throw a #PF after realising that the information it reaches is badcoded, but if (casually) the data the processor reaches is somehow valid? No little #PF and a HUGE problem.

[Nable]

I don't get your problem.
At first, mov eax, imm32 isn't likely to cause an exception (although it may do it if code memory isn't accessible), it looks like you've forgot square brackets (or messed AT&T and Intel syntax).
Second point is that there are flag bits in page directory entries, especially 'present' bit, so you can mark some areas as non-present and don't have to add leaf page tables for such areas.
See http://wiki.osdev.org/Paging for details.

There are also some estimates of space overhead for paging, you can find it here: http://wiki.osdev.org/Page_Tables

[KemyLand]

Sorry, missed the Present flag
Second, the mov thing was my error when typing. I didn't tried to mix syntaxes. (Result: mov eax, [0xFFFFFFFF] WITHOUT last page)
So the minimal is 4KB? (1024 PDEs * 4 bytes) I'm okay with that. Thanks!

[Combuster]

Theoretically, yes.

In practice, an empty page directory is a guaranteed crash - there's no code to run, which means there's no way out of the address space or to deal with errors. You typically need at least one but often three page tables for the contents of your process, and several more to contain all the necessary system structures to run the address space - even though as mentioned you can often reuse these for all processes.

In practice, a new address space with all the accounting typically costs you a 2-digit number of kilobytes, but that's still not a 2-digit number of megabytes.