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
o ...
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.
Enjoy,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
