L4 port of GNU Hurd

Re: Broken dream of mine :(

2009/11/4 Sam Mason <sam <at> samason.me.uk>:
> On Wed, Nov 04, 2009 at 12:39:05PM +0100, Michal Suchanek wrote:
>> This is not something that is completely addressed in Coyotos either -
>> there still can be observable increase in latency when the system is
>> under load. Coyotos aims to get nearer to the absolute isolation
>> ideal, though.
>
> AFAICT, it is possible to arrange things in Coyotos so that (say) things
> don't get swapped to disk and that memory is always available for the
> services that need it.  There were various discussions about this to do
> with windowing systems; for example, you want to know that you'll always
> be able to bring up a "task manager" to kill off offending processes,
> hence a way of reserving the appropriate resources for this in advance
> is needed.  This example involves quite complicated interactions between
> lots of different services needed to do its work and arranging all this
> is somewhat difficult.

You have completely missed the point. Even in Coyotos if you did not
pin your pages in memory so that they never get "swapped out" (and
most applications should not be able to pin) then your pages are much
more likely to get "swapped out" when other applications run (and
touch their pages)  than when the system is idle. While the "swap in"
may be transparent the latency is observable so you generally get the
same kind of information you get in Viengoos by observing the amount
of surplus memory available to you.

The ability to terminate processes is completely unrelated to this and
in any system that does reasonable resource management it is trivial
to implement. Most systems in use today do not guarantee the ability
to terminate rogue processes but that is a completely different issue.

(Continue reading)

headers

Sam Mason | 4 Nov 18:59

Re: Broken dream of mine :(

On Wed, Nov 04, 2009 at 03:02:33PM +0100, Michal Suchanek wrote:
> You have completely missed the point.

Hum, maybe.

> Even in Coyotos if you did not
> pin your pages in memory so that they never get "swapped out" (and
> most applications should not be able to pin) then your pages are much
> more likely to get "swapped out" when other applications run (and
> touch their pages)  than when the system is idle. While the "swap in"
> may be transparent the latency is observable so you generally get the
> same kind of information you get in Viengoos by observing the amount
> of surplus memory available to you.

Yes, but the "surplus memory" doesn't have to be accounted for on
a system wide basis.  It seems possible to place tighter bounds on
entities you're suspicious of.  These entities will only be able to
drive themselves into out-of-memory situations and not affected other
"compartments".  Side channels would seem to be cut down a lot, but so
is efficiency and if they need to talk to other services latency may
be visible there as well.  There must be lots of literature on this
subject---it's not really my area.

> The ability to terminate processes is completely unrelated to this and
> in any system that does reasonable resource management it is trivial
> to implement. Most systems in use today do not guarantee the ability
> to terminate rogue processes but that is a completely different issue.

On which systems in use today is this trivial?  I know I've (even
accidentally) brought several systems to their knees by such well known

(Continue reading)