Re: Swapping pagers out

[Marcus Brinkmann]

At Fri, 11 Feb 2005 15:38:40 +0100,
"address@hidden" <address@hidden> wrote:
> 
> Marcus Brinkmann <address@hidden> wrote:
> 
> > How does all of this answer your question?  Well, as soon as we have
> > this, physmem could in fact be made to swap out the whole task (except
> > for active DMA regions).  So, the constraints you mention that follow
> > from the tex document in the source would not apply anymore.
> 
> I don't think that any "default" pager should be able to swap out data
> (because the task may have data it doesn't want to be paged out to the
> swap, e.g. for security reasons, remember cached passwords).

Good point, although this could also be solved by making it
configurable (ie, you could mark physical frames you don't want to
have swapped out).

But I don't think anybody is actually trying to do that - we expect
that every task will get a contingent of physical frames and no
involuntary swap operation will take place.  I just mentioned it to
point out that by having physmem act as the last resort pager, a whole
task could completely be swapped out.  This does not mean that this
possibility is the original motivation for this design (it is not),
nor that we will implement it this way (highly unlikely) nor that it
is desirable (you gave one good reason why not to do it, although there
are work arounds).

The original motivation is to solve the important problems of allowing
to unmap pages, even pages used by the pager itself, temporarily, and
even before the task has completed its own initialization (ie, before
it could tell physmem about which parts would be dangerous to unmap -
for example in the startup code before the program is fully ELF
loaded).

> I assume a pager is able to swap out correctly all of the task data
> and text,

Yes.

Mmh, maybe.  Don't really know, maybe Neal can comment.  Certainly not
all the data, as at least the data about where the data was swapped
out to needs to be resident (or at least available via a last-resort
page fault to physmem).

It seems the following of your text addresses the question how to swap
out a whole task properly, without having physmem to do it on its own
will (which is indeed something we likely don't want - at least it
goes against our overall design goals of providing mechanisms, not policy).

> also with the data that represents page mapping for the task.
> However, the pager in this form is rather useless, so it should decide
> to "de-activate" itself by orderly swapping out its data and text. Just
> before deallocating the last page (the one holding the instruction
> pointer, which should at that time be somewhere near the beginning of
> the page), the pager asks the memory server to set its guaranteed
> pages to zero so they can be reused and sets its pager to some "other"
> thread. The page is then unmapped, which makes the thread fault.

Interesting.  Yes, I guess this would work.  This "other" thread would
at some time need to reactivate the task.  However, such a task would
be in deep hibernation indeed.  Because the pager thread itself is
blocked, no other faulting thread would be noticed by that "other"
thread, unless you modify all thread's pagers.  Mh.

> A system where this scheme would apply is obviously sufficiently
> complex to need a specialized server to make scheduling decisions.
> It may not be a good place to put that "other" pager thread, however it
> should somehow be informed that a task has been swapped out. Recieving
> a page fault is such an implicit message.
> 
> Indeed, a task that has completely been swapped out is not schedulable,
> but if the scheduler decides to schedule the task in spite of this
> (normally because memory is again available), it has to negotiate some
> memory for this task, to allow it to run. The disabled pager thread is
> then scheduled, which makes it fault. The "other" pager loads the last
> page that has been swapped out, it should contain code to restore the
> main pager code so that operation can be properly resumed.

My own feeling is that this seems overly complicated and quite
unnecessary.  The pager's resources can probably be reduced to a few
kilobytes.  This is not much, if you consider how many kernel
resources a task already occupies (two kilobyte per thread it
contains).  So, even if you have a lot of tasks, you should be able to
give each a bit of resident memory, and completely swapping out a task
is not a very important goal.  Am I wrong with this?

> I also feel that such a scheme could be used for task creation, since a
> task could start as a form of "swapped out image". The first thing to
> run would then be the pager thread.

Depends on the details.  For a suid application, the first thing that
must run immediately is the trusted injected code, which should not
block (it's communicating with the filesystem starting the suid
program).

For a normal task, which is in a full-trust relationship with the
started task, well, anything goes.  Whatever flies your boat and
actually works :) For such tasks, exec() will be completely
implemented in glibc, with just normal filesystem, task, physmem etc
support (mapping files, creating threads etc).

Thanks,
Marcus