[FreeVMS] pager question

BERTRAND Joël joel.bertrand at systella.fr
Sat Jun 29 22:21:38 CEST 2013


Guido a écrit :
> On Saturday 29 June 2013 18:10:16 BERTRAND Joël wrote:
>> 	When a process try to access to a unmapped page, it generates a
>> pagefault IPC. This IPC is received by an event handler loop in its
>> parent (for example, PAGER.SYS sends L4_PAGEFAULT IPC to VMSKERNEL.SYS
>> and all IPC are caught in sys/sys_loop.c).
>>
>> 	Child process does not know if its request can or will be done. It only
>> sends L4_PAGEFAULT IPC to its parent and waits for an answer. This
>> answer can be a new L4_MapItem() or a L4_AbortIpc_and_stop(). Thus, I
>> don't see why we need to separate L4_PAGEFAULT IPC in two IPC calls.
>
> The question is if the the process should try to access an unmapped page if it
> actually tries to allocate memory. Shouldn't the process try to request more
> pages first and wait for them to be mapped into its address space before it
> tries to access them?

	With L4, you only map a page in process address space when you try to 
access to this page.

> It seems to me that this makes the pagefault handling algorithm needlessly
> complex. The algorithm could as simple as "if the page is mapped, load it from
> cache or swap, otherwise kill the process". A pagefault should be an exception
> not a function.

	L4_PAGEFAULT IPC is sent when a process tries to access to unmapped 
memory. Process sends this IPC when it is loaded in memory too. Thus, I 
think we have to use a second syscall to indicate to pager two modes :
1/ process can request memory (initialization or brk()) ;
2/ process has to be stopped (access violation).

> IMHO a page fault and a memory request are completely different and should not
> be combined into one IPC call. I'm afraid that combining them will in de long
> run this only hurt reliability, stability and maintainability of the OS.

	On L4, you only have one IPC. But you can add other IPC's to switch 
between more than one functions.

	Regards,

	JKB


More information about the FreeVMS mailing list