shrinking memory consumptions
Mike C. Fletcher
mcfletch at vrplumber.com
Mon Apr 2 15:28:48 EDT 2007
Ivan Krstić wrote:
> Jim Gettys wrote:
>> Oh, I understand all right. And ran it by those who really understand
>> the Linux kernel. You end up in all sorts of deadlock hell if you try
>> to rely on user space for anything; at most you can hint to user space
>> that memory is getting low.
> No -- I explicitly said I'm proposing a non-polling, non-blocking
> notification mechanism that's _orthogonal_ to the existing OOM killer
> functionality. There's no deadlock hell here. You're calling the same
> thing a 'hint'. We're in violent agreement.
> Fundamentally, this is a user experience issue. Applications
> disappearing without any explanation, and for reasons completely
> unrelated to user actions (such as running low on memory) clearly isn't
> the user experience we want to provide. A userland application quit
> chooser, driven by a low-memory hint from the kernel and with a sane
> default application preselected for quitting -- chosen by some of the
> heuristics you mention -- is pretty obviously superior from a user
> experience point of view. And if the user takes too long to answer or
> the remaining memory dries up because something is allocating it very
> quickly, well, let the OOM killer go to town.
I believe Ivan is suggesting a UI mechanism that allows for configuring
the OOM killer. This mechanism would likely look something like this:
* In low memory situations, which applications should we close first
(move applications up in the list to close them first)?
o Web Browser (this application is generally capable of saving
your work before closing), generally frees > 5MB
o Television Viewer (this application is generally capable of
saving your work before closing), generally frees < 5MB
o Email Client (this application is not known to be capable of
saving your work before closing!), generally frees > 8MB
Where we would have applications which are capable of saving state/work
before being killed marked as such in their application bundles. The
user would be able to choose the application name and the OOM Killer's
hit-list would be updated when we start/close each application (that is,
we update the hit-list at application start or reconfiguration, we don't
generate it when the OOM is trying to run). It would be nice if we
could automatically track total memory usage over time to update the
statistics so that the children could see how much they gain by putting
one application earlier in the list than the others.
In a low-memory situation, the same mechanism can be popped up with the
individual instances shown as well to allow for reordering individual
web-browsers before others, for instance, but the user's general
preference can be used if the user doesn't decide to rearrange the
priorities when the warning comes up.
Anyway, just trying to make the discussion more concrete.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Devel