[sugar] Memory allocation indicators

Benjamin M. Schwartz bmschwar
Thu Mar 13 16:28:51 EDT 2008


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.




More information about the Sugar-devel mailing list