3 ms·

This is an obvious idea, so I presume there's a reason why it wouldn't work, but what would happen if you had different rules for uid=0 pids and for everything

This is an obvious idea, so I presume there's a reason why it wouldn't work, but what would happen if you had different rules for uid=0 pids and for everything else? If processes running as root were never eligible for oom-killing, and could force mallocs by triggering an oom-kill of user processes as necessary, wouldn't you always be able to recover a thrashing system from a root console? Or is it too hard to isolate console IO from the rest of the system in that situation?

mschuster91 7y ago
Many systems (embedded and phones) don't have a proper root console, and people still run daemons which can leak memory as root.
- regularfry 7y ago
  Yeah, not having a root console on those systems means they're in no better (or worse) a situation than today. I think misbehaving root processes are a different case, though: any misbehaviour as root can have dire consequences, which is why running as root is a Bad Plan in general. Would adding "...and oom behaviour can wedge the box in new and interesting ways" to the list make things worse than they are today?
malux85 7y ago
Read the source code of the OOM killer, the way that it computes the badness score favours userland processes, but root processes must also be considered because it’s possible they misbehave too
- regularfry 7y ago
  Possible, yes, but the smaller number of root processes and their general higher-risk status implies that a different policy entirely might be better than the same policy with different parameters. Besides which, I'm looking at https://github.com/torvalds/linux/blob/master/mm/oom_kill.c https://github.com/torvalds/linux/blob/master/mm/oom_kill.c and I genuinely can't see where root processes get privileged. I can see a reference to a `root bonus` in a comment, but other than that... maybe my kernel source reading skills are just too rusty.
mort96 7y ago
The issue isn't that the OOM killer is too aggressive and killing the consoles or shells you're trying to use to rescue your system. The issue is that when you're trashing, the system becomes unresponsive; it's hard to recover the system because it takes many minutes to even just switch to a TTY.
- regularfry 7y ago
  That's kind of where I'm trying to get to, I think: how can you segregate the system such that root processes get a priority such that they don't get affected by the thrashing?

mschuster91 7y ago

Many systems (embedded and phones) don't have a proper root console, and people still run daemons which can leak memory as root.

regularfry 7y ago
Yeah, not having a root console on those systems means they're in no better (or worse) a situation than today. I think misbehaving root processes are a different case, though: any misbehaviour as root can have dire consequences, which is why running as root is a Bad Plan in general. Would adding "...and oom behaviour can wedge the box in new and interesting ways" to the list make things worse than they are today?

malux85 7y ago

Read the source code of the OOM killer, the way that it computes the badness score favours userland processes, but root processes must also be considered because it’s possible they misbehave too

regularfry 7y ago
Possible, yes, but the smaller number of root processes and their general higher-risk status implies that a different policy entirely might be better than the same policy with different parameters. Besides which, I'm looking at https://github.com/torvalds/linux/blob/master/mm/oom_kill.c https://github.com/torvalds/linux/blob/master/mm/oom_kill.c and I genuinely can't see where root processes get privileged. I can see a reference to a `root bonus` in a comment, but other than that... maybe my kernel source reading skills are just too rusty.

mort96 7y ago

The issue isn't that the OOM killer is too aggressive and killing the consoles or shells you're trying to use to rescue your system. The issue is that when you're trashing, the system becomes unresponsive; it's hard to recover the system because it takes many minutes to even just switch to a TTY.

regularfry 7y ago
That's kind of where I'm trying to get to, I think: how can you segregate the system such that root processes get a priority such that they don't get affected by the thrashing?