Re: making paging decisions

[Neal H. Walfield]

> But then, you have not said much at all yet about how the number of
> guaranteed frames is determined, and how it can (if at all) change
> over the run time of a task (and what happens if there is memory
> pressure).

Indeed.  This is a problem.  What I have in mind is having a per-user
"policy" combined with a economic model of short and long term loans.
The former being more tested; the latter more academic.  The former
seems natural to me as a user will want its processes to always run
with the minimum amount of memory as then more memory is available to
its tasks when they have a memory usage spike.  (Again, we place the
onus on the user to do the right thing as it will only hurt itself.)
Nevertheless, there needs to be a mechanism to determine how much
memory to grant to each user and how to adjust to the number of users
on a multi-user system.

> If we give too little guaranteed frames, then all (or some) tasks in
> the system will be hopelessly swapping.

No.  Look at VMS on which the design of physmem is closely modeled: it
works really well and all tasks have a fix number of physical pages
for their entire lives.  VMS does not allow renegotiation.

So, how does VMS work?  Well, it provides two levels of "swap" just as
we do.  When a task discards a frame, VMS enters it onto a
to-be-evicted list and only evicts it when there is memory pressure.
We do the something similar: filesystems will keep a cache so if your
process needs to free some frames and then use them again later it is
only a question of asking the server; not going to disk.  Likewise
with anonymous memory.  In this case, physmem only flushes to swap
when it has to.  If a task requests a frame earlier then it is made
available immediately.  Do the extra contect switches matter?  Well,
they don't in VMS.