On Mon, Apr 02 2007, Ivan Krsti?? wrote: > 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.
OOM is pretty simple to get right, when you have the chance to tailor it to a custom setup like this one. In general it's next to impossible to get right. But that is why I made the distinction between low mem and OOM. > 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". Of course, OOM is always just a last resort. It'll get rid of an application, but it's not very polite. I like your approach with a gui warning and all, it'll work fine as long as the rate of memory allocations doesn't get you into problems before the user has selected a process to (checkpoint, if possible, and) quit. -- Jens Axboe _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
