No surprise on memory

[Albert Cahalan]

[multiple people]

> I recently learned a few very important things about Linux memory
> management (I'm speaking about how its supposed to work, irrespective
> of any bugs).  Operating systems experts already know all of this,
> but I did not.

This is a good reminder for those of us who tend to assume that
anyone joining these discussions is an OS expert.

> Conclusion: no magic get-out-of-jail-free card.

There certainly isn't anything that can work with perfect
reliability, even if policy was to disable overcommit and
check malloc everywhere.

Pay particular attention to how every proposed solution meets
the real goals, remembering that nearly all activities save the
user's data via a non-atomic process that requires memory.
Simply put, it is never acceptable to force a well-bahaved
activity to die or live without the memory it demands.

>> It may be interesting to adjust the OOM score of some applications.
>> This way it should be possible to protect the core applications
>> (sugar-shell, journal, X, ...) from being killed in an OOM situation.
>
> I'm with Benjamin here, if the OOM killer kicked in soon enough and
> activities were clearly marked as first candidates to be killed,
> stability would be much much better.

No way.

The core applications only exist for the desired activity. If that
desired activity must die, you might as well power off the laptop.
The only processes slightly worth saving are klogd and syslogd,
allowing developers to figure out what just happened.

> And if background activities were killed before the active one,
> we would avoid data loss.

Background activities can contain valuable unsaved state too.
Of course, this is somewhat theoretical because kids do not
intentionally have background activities. The ten activities running
in the background on a typical kid's XO are a big contributer to
these memory problems.

> Combine that with Mac OS (pre X) style "estimated memory allocation"
> metadata for each activity and the user experience could perhaps even
> work.

This is key. Until the UI absolutely refuses to let the user start
a set of 2+ activities that could run out of memory, memory problems
are a given. For activities with unbounded memory usage, this means
they get the machine exclusively.