On Mo, 06.01.20 14:53, Michael Catanzaro (mcatanzaro@xxxxxxxxx) wrote:
> On Mon, Jan 6, 2020 at 7:09 pm, Lennart Poettering <mzerqung@xxxxxxxxxxx>
> wrote:
> > - 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 submit
> > 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
unit files.
I mean, OOMPolicy= currently can be set to "stop", "kill" or
"continue", where "stop" means "when a process of service X is OOM
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".
The expectation here is that most services will want "stop" but
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.
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
