l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EROS/Coyotos fault handers vs l4 pager hierarchy


From: Jonathan S. Shapiro
Subject: Re: EROS/Coyotos fault handers vs l4 pager hierarchy
Date: Mon, 24 Oct 2005 14:56:55 -0400

On Sun, 2005-10-23 at 20:33 +0200, Marcus Brinkmann wrote:
> At Sun, 23 Oct 2005 13:25:33 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > 
> > On Sat, 2005-10-22 at 12:39 +0200, Marcus Brinkmann wrote:
> > > That's not a bad counter-example.  Except that in the Hurd/L4 design,
> > > swapping is voluntary and explicit.
> > 
> > What happens when you run out of physical pages and you want to start a
> > new process? Given that the vast majority of processes are untrusted,
> > how to you guarantee that they give up storage?
> 
> Well, those are good questions, and we didn't find a satisfactory
> answer yet.
> 
> Neal's idea was that the guaranteed physical memory contingent that a
> process (or user) receives is negotiated in a long-term contract,
> which periodically must be renegotiated.  At renegotiation time, the
> process gets a chance to swap pages out to disk.  After this chance
> passed, pages may be revoked forcefully.
> 
> Renegotiation of resources could for example handled with a
> market-model.

I am somewhat amused. The foundational papers on this sort of thing are
the ones published in a collection edited by B.A. Huberman entitled "The
Ecology of Computation". Regrettably, it is now out of print, but the
three most important papers can be found at:

        http://www.agorics.com/Library/agoricpapers.html

Mark Miller is currently simulating a PhD student in my lab.

The bad news: what you propose, in essence, is that all of the processes
in the system should get together and communicate periodically to
renegotiate their needs on a presumptively friendly basis. The entire
approach just doesn't work in a world where hostile programs are a
reality.

shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]