On Mon, Apr 02 2007, 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.
That remains to be seen. I'm sure I don't need to remind anyone of Brooks' 2nd and 3rd system redesign principles :-) > > 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. Yep I agree with that, if possible we should definitely avoid getting into OOM in the first place. -- Jens Axboe _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
