[FreeVMS] pager question

[Renee]

This process is good for me because it brings my memory back. 

-----Original Message-----
From: FreeVMS [mailto:freevms-bounces at rayleigh.systella.fr] On Behalf Of
BERTRAND Joël
Sent: Saturday, June 29, 2013 6:44 AM
To: FreeVMS mailing list
Subject: Re: [FreeVMS] pager question

Guido a écrit :
> Hi all,

	Hello,

> Looking at the pager algorithm I noticed that a page fault in user 
> space could lead to allocation of a new page for the process that 
> generated the page fault.

	Right.

> Maybe I'm missing something, but it seems to me that that is not 
> desired behavior. Buggy or malicious software in user space should not 
> be able to acquire resources simply by accessing invalid memory 
> addresses. In stead this should lead to an access violation and 
> termination of the originating process.

O It seems this process is devoid of acknowledgement that sysgen existed and
was an important part of resource allocation and limiting said allocation.

	I agree. For kernel itself, sys_pagefault always returns new
ressources. For an unprivilegied process, pager has to save a list of
allocated pages for this process.

O I should add that the database in memory was complex.


 Pagefault handler only has to return new pages when process is loaded in
memory, when stack is growing or when process uses something like mmap() or
brk(). In all other cases, pagefault has to raise a new syscall to kill
process.

Again process defaults are set by sysgen.

> I'd suggest that page fault handling and mapping/granting memory are 
> entirely separate functions. A page fault on a page that is not mapped 
> is an access violation and should lead to termination of the 
> originating process. If the page is mapped, the pager could (like 
> OpenVMS does) distinguish between soft and hard page faults. A soft 
> page fault means that the page still resides somewhere in cache, while 
> a hard page fault means it is swapped out and has to be loaded from disk.
This depends on the paging algorithm.

	I agree.

> Memory allocation and mapping/granting pages is something completely
different.
> My suggestion would be that allocation requests by user tasks are 
> handled by the task pager. If the task pager runs out of memory it can 
> request one or more pages from the main pager through a page request 
> system call. The main pager can map/grant a page from the free page 
> pool it maintains or, if the pool is empty, it can request a new page 
> from the kernel. If the kernel runs out of free pages, the pager 
> should free up some pages by swapping out some pages to disk. Note 
> that this could (should?) be optimised by initially mapping/granting 
> all free pages to the main pager, so that the pager does not have to 
> use system calls to request memory from the kernel once the system is up
and running.
>
> I could be wrong, of course ...

	No, I don't think. In a first time, I propose that task pager
doesn't use swapped memory as we need disk I/O drivers to handle swap and as
these drivers require task pager.

	Kickstart loads L4/X2, sigma0 and several modules :
- vmskernel.sys (uses sigma0 pager) ;
- pager.sys (main pager that use sys_pagefault) that is launched _without_
swapped memory area as disk I/O are not available ;
- dq driver + partionning to add swapping capabilities.

	Renee