shrinking memory consumptions

[Mike C. Fletcher]

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