Hi Austin, On 05/13/2016 03:11 PM, Austin S. Hemmelgarn wrote: > On 2016-05-13 08:39, Sebastian Frias wrote: >> Well, a more urgent problem would be that in that case overcommit=never is >> not really well tested. > I know more people who use overcommit=never than overcommit=always. I use it > myself on all my personal systems, but I also allocate significant amounts of > swap space (usually 64G, but I also have a big disks in my systems and don't > often hit swap), don't use Java, and generally don't use a lot of the more > wasteful programs either (many of them on desktop systems tend to be stuff > like office software). I know a number of people who use overcommit=never on > their servers and give them a decent amount of swap space (and again, don't > use Java).
Then I'll look into LTP and the issues it has when overcommit=never. >> >> My point is that it seems to be possible to deal with such conditions in a >> more controlled way, ie: a way that is less random and less abrupt. > There's an option for the OOM-killer to just kill the allocating task instead > of using the scoring heuristic. This is about as deterministic as things can > get though. I didn't see that in Documentation/vm/overcommit-accounting or am I looking in the wrong place? >> >> Well, it's hard to report, since it is essentially the result of a dynamic >> system. >> I could assume it killed terminals with a long history buffer, or editors >> with many buffers (or big buffers). >> Actually when it happened, I just turned overcommit off. I just checked and >> is on again on my desktop, probably forgot to make it a permanent setting. >> >> In the end, no processes is a good candidate for termination. >> What works for you may not work for me, that's the whole point, there's a >> heuristic (which conceptually can never be perfect), yet the mere fact that >> some process has to be killed is somewhat chilling. >> I mean, all running processes are supposedly there and running for a reason. > OTOH, just because something is there for a reason doesn't mean it's doing > what it's supposed to be. Bugs happen, including memory leaks, and if > something is misbehaving enough that it impacts the rest of the system, it > really should be dealt with. Exactly, it's just that in this case, the system is deciding how to deal with the situation by itself. > > This brings to mind a complex bug involving Tor and GCC whereby building > certain (old) versions of Tor with certain (old) versions of GCC with -Os > would cause an infinite loop in GCC. You obviously have GCC running for a > reason, but that doesn't mean that it's doing what it should be. I'm not sure if I followed the analogy/example, but are you saying that the OOM-killer killed GCC in your example? This seems an odd example though, I mean, shouldn't the guy in front of the computer notice the loop and kill GCC by himself? Best regards, Sebastian
