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. _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
