OSDev.org

Hello

I'm asking your advice in choosing between two ways in doing memmap of each process:

1- Reserve about ~ 4MB space for PD & PTs for all process, keep each process memmap in its context, and when context switching just write the replace/and/or write the entries of process memmap to the PD & PTs.
This has the disadvantage of writing the whole memmap of the process during the context switching.

2- Reserve a PD & PTs for each process, so all we need during context switching is to chage CR3 to the new PD and voila.
This has the disadvantage of consuming alot of memory, and the difficaulty of founding 4k aligned free-space easily.

Knowing that i'll invlp and flush the TLBs.

So
which method is better in your opinion?
which method is more commonly used in gr8 OSes like linux, ...?

Thanks alot

For small processes you need only a page directory and ~one page table; Additionally, you have to map your kernel memory somewhere in the PD; in our kernel, for example, the last 256 PDEs of each process point to shared kernel PTs. Other entries in PD should be marked not present. You can then add PTs in the page fault handler as needed...

This is not my problem, i know all of that
i was asking which is better during context switching, just change the CR3 to point to the PD of the process going to run, or to set 1 PD with 1024 PTs and use them for all the process, where i would copy the PD & PTs information from a each process structures in each context, so the CR3 in this case in constant just contents of the PD & PTs itselves change????

Thanks alot

Use a separate page directory for each process, this would be a lot faster and more scalable to multi-processing, if you ever intend to support it.

Cheers,
Sean

This means that i will need to reserve upto 4MB for each process

This means that i will need to reserve upto 4MB for each process

No you don't have to reserve 4 MiB as the paging mechanism uses two levels:

When a new process is started all you do is creating an empty directory. As long as the directory desn't yet point to any entries only 4 KiB of memory are wasted. As soon as the first page gets allocated a table must be inserted into the directory. A table occupies 4 KiB and allows you to map 4 MiB of virtual-memory to an application. As they can be added and removed dynamically the paging structures never take more than 1/1024 of the virtual memory they manage.

regards,
gaf

Uh, not necessarily.

The standard way:
You need to allocate a page directory, and only the page tables you want to use. A small program easily stays under 4MB of memory usage, and only needs one or two page tables out of the 1024 possible. The kernel has his own global set of page tables which you insert into the page directory wherever you need it.

So for each program you only need to allocate:
- kernel resources (kernel stack, task info structures, and so on) - in my old kernel i needed just 2 blocks of memory for each task.
- page directory (1 4k block)
- page table (1 block for small applications, more for larger ones, depends on the memory layout)
which equals 4*4k = 16kb overhead for one process. thats way below the 4MB of memory to be reserved.

On top of that, you allocate space for code, data, heap and stack as the application needs.

What you can do is reserve 4MB of address space (not memory) to be paged in with the page tables when needed. This adds another 4k of overhead for another page table. the consequence is that you get a stretch of 4MB of virtual memory that is not paged in, and as such consumes no memory until you need it.