[sugar] Memory allocation indicators

[Benjamin M. Schwartz]

On Thu, 2008-03-13 at 16:03 -0400, Michael Stone wrote:
> > Also, it would be easy for Rainbow to enforce a pre-set hard limit on
> > memory usage for each Activity separately.  
> 
> I've thought about it before, but I don't think it leads to a good UI at
> the moment. The problem is that I don't think you really want to nuke
> activities that hit their hardlimit, or to start returning ENOMEM to
> ones that hit the soft (memory) limit.

I agree, though I would say it in reverse: in order to ensure that
correctly functioning activities don't hit their limits, the limits
specified in activity.info would have to be so high that only a few
activities could run simultaneously.

> > I think that this is very interesting, since it would allow us to
> > ensure that OOM never happens, by only launching an activity if all
> > activities could still max out their quota afterwards.  
> 
> This safety property only seems to be true if we can give reasonable
> upper bounds on _all_ the software that we're trying to run, no?
This is a good point.  User "olpc" would also have to run with memory
limits, and sugar would have to be debugged to the point that it could
safely run within these bounds.

> P.S. - Ivan and I once kicked around the idea of modifying the 'hard'
> 'soft' limits notion into a 'sleepy' limit notion. In implementation,
> this might consist of sending SIGSTOP rather than SIGKILL and blocking a
> malloc() rather than returning ENOMEM until pressure is eased.
> Unfortunately, this hasn't gone beyond the drawing board.

That's an interesting proposal, though it replaces OOM with a state in
which all processes are SIGSTOPed one by one.

I recall a complementary design in which, when a few MB of free memory
remained, the kernel would call a userspace "OOM prevention handler",
which would SIGSTOP all activities and then present the user with a
modal dialog to kill one of them.  IIRC, there is currently no support
for this in the kernel, and so it has remained on the very large back
burner.