On Tue, 2020-01-07 at 11:28 +0100, Lennart Poettering wrote:
On Mo, 06.01.20 14:53, Michael Catanzaro (mcatanzaro(a)gnome.org)
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering <mzerqung(a)0pointer.de>
> > - facebook is working on making oomd something that just works for
> > everyone, they are in the final rounds of canonicalizing the
> > configuration so that it can just work for all workloads without
> > tuning. The last bits for this to be deployable are currently being
> > done on the kernel side ("iocost"), when that's in, they'll
> > oomd (or simplified parts of it) to systemd, so that it's just there
> > and works. It's their expressive intention to make this something
> > that also works for desktop stuff and requires no further
> > tuning. they also will do the systemd work necessary. time frame:
> > half a year, maybe one year, but no guarantees.
> Asking around, I understand oomd only operates at the cgroup level, i.e. it
> kills an entire cgroup at once, not individual processes. So I understand
> this would also depend on GNOME-level work to ensure individual applications
> get launched in their own systemd scopes, yes?
That would be a good idea, yes. But there'd be a knob for that in the
I mean, OOMPolicy= currently can be set to "stop", "kill" or
"continue", where "stop" means "when a process of service X is
killed, attempt to shutdown all of X in a friendly way"; "kill" means
"when a process of service X is OOM killed, forcibly kill all other
processes of X too"; "continue" means "if a process of service X is
OOM killed, do nothing else".
Yep, changing the OOMPolicy was considered at first. But creating new
scopes for spawned children is simple enough and it also solves some
other issues (e.g. not killing children when gnome-shell is restarted).
The expectation here is that most services will want "stop"
services that are more "application servers" than an individual
service (think: apache with its cgi scripts or crond with its
cronjobs) would set OOMPolicy=continue, since if one of their jobs
misbheaves they probably should continue running.
But yeah, the focus where things are going are clearly towards making
a cgroup the unit that is managed as a whole.