Jens Axboe wrote: > Didn't figure I would :-) And yeah, I don't mind taking a look at low > memory and OOM situations.
I don't really know that there's that much to work on with regards to OOM. When we hit OOM, we've lost already -- we need to make an arbitrary decision to kill something, and there's no good heuristic to make sure we don't kill whatever is most precious to the user at the moment. In my mind, the OOM solution is a relatively straightforward one: when -- sans buffers and cache -- we've allocated 256-x MB, with x being 5 or 10, the kernel emits a warning to userland through some interface (netlink? something else we can epoll?). Sugar picks up warning, freezes execution of currently-running activity, and gives the user a "low memory; pick an application to close" chooser. After the user makes the selection, the target application is sent a 'save anything you have open and emergency close' message via D-BUS, and terminated seconds later if it fails to comply. If I remember correctly my conversation with Sampsa of the Maemo team at Nokia, they wanted to do something similar. All of the above can be implemented today, except we'd have to poll; optimizing that to be epollable is worth it, but either way, I strongly believe OOM should be a last resort, not a "solution". -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
