shrinking memory consumptions
jg at laptop.org
Mon Apr 2 14:06:49 EDT 2007
On Mon, 2007-04-02 at 13:01 -0400, Ivan Krstić wrote:
> Jim Gettys wrote:
> > It need not be arbitrary: it can be the activity that was used longest
> > ago/crossed by total memory usage.
> That's arbitrary. Please, please don't keep going down this road of
> thinking -- you can't develop better heuristics than asking the user
> what she wants to close. Ask the scheduler guys how much of a PITA it
> was for them to insert little sleep counters all over the scheduling
> code so that they could, in theory, prioritize "active" applications for
> scheduling... and how fragile it was, and why a bunch of people are
> thrilled by Con Kolivas' recent RDSL work that'll completely get rid of
> such heuristics when it gets merged.
Having apps save themselves periodically so they can be transparently
restarted is I think the right goal.
> > This is only slightly a kernel issue. What's really needed is for user
> > space to tell the kernel what the priorities are on what to shoot.
> You can do that today; /proc/x/oom_adj and check your current score via
> /proc/x/oom_score. But we can do better -- our efforts should go towards
> not hitting OOM in the first place.
> > Warning from the kernel doesn't work: you can deadlock.
> No. A notification mechanism, as I propose, should be completely
> orthogonal to the OOM killer. It's a "hm, we have 5 megs left, warn
> userland, maybe they kill something and we never hit OOM" approach. If
> we do hit OOM, let the OOM killer do its thing. I'm clearly not
> proposing that it block on an answer from userland. I'm proposing
> essentially an optimization that turns an already-viable solution into
> something that we don't have to poll.
Sorry: that's not the way the kernel works; for example, in can come
packets, and you can't wait on user space to do anything. I've already
been down this path with true kernel guru's....
At best you can tell the kernel what order in which to shoot things, and
that capability is there.
One Laptop Per Child
More information about the Devel