On 13/01/2020 05:24, Per Jessen wrote:
Why should this be different? What's the object to alter the default behaviour of the OOM_killer so that it kills the process that caused the OOM?
That's no better than the default. Still plenty of options for killing an innocent process.
I will grant you that the people who write technical documentation are often not the best at precisely expressing the purpose and intent, and even we two see subtle differences in the way we've grown up using the English language, but this one puzzles me. "Innocent"? To my mind an innocent process is one that didn't cause the OOM. Now the way I read the docco there are two settings. One walks though the process table killing of processes. In all probability the first one will be innocent. How much memory will be released? Why should the OOM_killer proceed to another one? The docco does make clear just what constitutes 'necessary' and 'sufficient' in this case. Bad Docco! The alternative setting causes the OOM_killer to select, first and foremost, the process that caused the OOM. Certainly if this is a nasty_process for any one of a number of reasons such as a a pernicious memory leak, then this strikes me as a sensible move. The docco also notes that there are ways to take memory dump and debug why this happens. Well, that's a bit of a techie/geek outlook, isn't it. Thee and Mee in a production environment won't have time for all that. Like Der Furhur in Mahogany Row says "Get It Running Again And Keep It Running This Time!" That's what the customers want, that's what the shareholders want. Who are we mere myrmidons to deny them that? So the nasty_process that caused the OOM is killed off, freeing memory. Now we're back in the situation where that randomly selected, possibly - nay, probably - innocent process was killed. "Now What"? What constitutes "necessary" and "sufficient"? What happens next? There are two possibilities here. The one I see is that the whole things finishes there. The immediate cause for the OOM has gone, memory is free. Other process,, ALL other processes continue. Perhaps in case #1 the nasty_process continues, continues to leak memory, and eventually causes another OOM. This is why I prefer case #2. Kill The Bugger. Then everyone else can proceed. The second is that there are some 'hidden variables' about what constitutes 'necessary' and 'sufficient' and the OOM_killer keeps killing process, certainly in setting case 1 and now setting case 2 has degenerated into case 1. the documentation doesn't say anything about what happens next. BAD DOCCO! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org